However, as of today, no deprecation warning of any sort is emitted when the API is used.
Ultimately removing the old untyped API would allow to easily reclaim 8B on every T_DATA which could be used by the newly introduced embedded TypedData objects https://github.com/ruby/ruby/pull/7440
Was there any discussions about removing the old API at some point?
Could we emit a warning when the API is used? Either verbose or non-verbose, to at least surface the issue to gem owners? This would help drive the effort to fix outdated gems, allowing to eventually remove this old API in the future.
Looking at our big applications dependencies, there seem to be a small minority of gems still using the old API:
I do not have anything against the proposal itself, but in
regards to "This would help drive the effort to fix outdated
gems", I believe this to be slightly too optimistic. Many gems
that have not been updated in, say, 2-3 years, are probably
no longer (actively) maintained (for the most part). One can
see that on gems hosted on rubygems.org: many gems have one
peak activity of several releases, and then no more update
for years to come. So I believe the primary (better) argument
to be made should be rather in regards to "reclaim 8B on every
T_DATA" or deprecation handling in general (e. g. since as of
the year 2010) than assume adoption of older gems. If the ruby
devs communicate a strategy of change - and have given enough
time to adjust - then I think ruby should move forward towards
change (in general, that is; again, I don't have any particular
opinion on this issue; I don't think it affects me either way,
though of course reading "reclaiming xyz" sounds great - as matz
once said, nobody minds more speed/efficiency).
Which IMO confirms that just marking something as deprecated in the documentation has little effect, and some form of deprecation warning would help at least some gems upgrade.
Generally deprecation and migration takes development cost for gem developer.
Therefore such proposal needs to clearly shows the merit of the removal.
("marked as deprecated" is not such reason)
About the strategy of C API deprecation, runtime warning is not a good way because such warning make the gem unusable.
As byroot originally says first it should show a build time warning, then just remove the API is reasonable.
If the migration really has the benefit, gem owners should fix the usage.
Therefore such proposal needs to clearly shows the merit of the removal.
I mentioned why I'd want it removed. It would allow to reclaim 8B per objects, allowing T_DATA to be 32B rather than 40B, and we have plans to make slot sizes powers of two.
Alright. A big part of the API is composed of macros, so I'm not too sure how we can effectively make them emit a build time warning, but I'll see what I can do.
Discussed at the dev meeting. Matz accepted build-time warning.
However, the author of a gem that is not well maintained is not likely to notice the build-time warning. Whether it is actually possible to remove the APIs may require careful consideration in the future.
Whether it is actually possible to remove the APIs may require careful consideration in the future.
Agreed. I'm not suggesting that yet. However I do have a proof of concept that degrades a bit the old API performance in favor of improving the new API performance, so having the API explicitly marked as deprecated help justify this kind of changes.
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by