Issue #19998 has been updated by Eregon (Benoit Daloze). Maybe we should deprecate the corresponding C functions instead/in addition to runtime warnings? i.e. the fix is in C extensions, not Ruby code. +1 on deprecating those, it would simplify to have one (TypedData) instead of two data-like types. ---------------------------------------- Feature #19998: Emit deprecation warnings when the old (non-Typed) Data_XXX API is used https://bugs.ruby-lang.org/issues/19998#change-105257 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- The replacement API was introduced in Ruby 1.9.2 (2010) [Feature #3064], and the old untyped data API was marked a deprecated in the documentation as of Ruby 2.3.0 (2015): https://github.com/ruby/ruby/commit/98544c372d948717de22afc86d162e411f1fb5f1 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: - https://rubygems.org/gems/unf_ext (https://github.com/knu/ruby-unf_ext/pull/72) - https://rubygems.org/gems/rotoscope - https://rubygems.org/gems/re2 - https://rubygems.org/gems/mysql2 Migrating them over doesn't seem too hard. -- https://bugs.ruby-lang.org/

Issue #19998 has been updated by rubyFeedback (robert heiler). 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). ---------------------------------------- Feature #19998: Emit deprecation warnings when the old (non-Typed) Data_XXX API is used https://bugs.ruby-lang.org/issues/19998#change-105266 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- The replacement API was introduced in Ruby 1.9.2 (2010) [Feature #3064], and the old untyped data API was marked a deprecated in the documentation as of Ruby 2.3.0 (2015): https://github.com/ruby/ruby/commit/98544c372d948717de22afc86d162e411f1fb5f1 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: - https://rubygems.org/gems/unf_ext (https://github.com/knu/ruby-unf_ext/pull/72) - https://rubygems.org/gems/rotoscope - https://rubygems.org/gems/re2 (https://github.com/mudge/re2/pull/116) - https://rubygems.org/gems/mysql2 Migrating them over doesn't seem too hard. -- https://bugs.ruby-lang.org/

Issue #19998 has been updated by naruse (Yui NARUSE). 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. ---------------------------------------- Feature #19998: Emit deprecation warnings when the old (non-Typed) Data_XXX API is used https://bugs.ruby-lang.org/issues/19998#change-105555 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- The replacement API was introduced in Ruby 1.9.2 (2010) [Feature #3064], and the old untyped data API was marked a deprecated in the documentation as of Ruby 2.3.0 (2015): https://github.com/ruby/ruby/commit/98544c372d948717de22afc86d162e411f1fb5f1 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: - https://rubygems.org/gems/unf_ext (https://github.com/knu/ruby-unf_ext/pull/72) - https://rubygems.org/gems/rotoscope (https://github.com/Shopify/rotoscope/pull/99) - https://rubygems.org/gems/re2 (https://github.com/mudge/re2/pull/116) - ~~https://rubygems.org/gems/mysql2~~ (use either API to support old rubies) Migrating them over doesn't seem too hard. -- https://bugs.ruby-lang.org/

Issue #19998 has been updated by byroot (Jean Boussier). But a build time warning at least would be a good way to prevent new gems from being written using that API. ---------------------------------------- Feature #19998: Emit deprecation warnings when the old (non-Typed) Data_XXX API is used https://bugs.ruby-lang.org/issues/19998#change-105565 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- The replacement API was introduced in Ruby 1.9.2 (2010) [Feature #3064], and the old untyped data API was marked a deprecated in the documentation as of Ruby 2.3.0 (2015): https://github.com/ruby/ruby/commit/98544c372d948717de22afc86d162e411f1fb5f1 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: - https://rubygems.org/gems/unf_ext (https://github.com/knu/ruby-unf_ext/pull/72) - https://rubygems.org/gems/rotoscope (https://github.com/Shopify/rotoscope/pull/99) - https://rubygems.org/gems/re2 (https://github.com/mudge/re2/pull/116) - ~~https://rubygems.org/gems/mysql2~~ (use either API to support old rubies) Migrating them over doesn't seem too hard. -- https://bugs.ruby-lang.org/

Issue #19998 has been updated by byroot (Jean Boussier). 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. ---------------------------------------- Feature #19998: Emit deprecation warnings when the old (non-Typed) Data_XXX API is used https://bugs.ruby-lang.org/issues/19998#change-105761 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- The replacement API was introduced in Ruby 1.9.2 (2010) [Feature #3064], and the old untyped data API was marked a deprecated in the documentation as of Ruby 2.3.0 (2015): https://github.com/ruby/ruby/commit/98544c372d948717de22afc86d162e411f1fb5f1 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: - https://rubygems.org/gems/unf_ext (https://github.com/knu/ruby-unf_ext/pull/72) - https://rubygems.org/gems/rotoscope (https://github.com/Shopify/rotoscope/pull/99) - https://rubygems.org/gems/re2 (https://github.com/mudge/re2/pull/116) - ~~https://rubygems.org/gems/mysql2~~ (use either API to support old rubies) Migrating them over doesn't seem too hard. -- https://bugs.ruby-lang.org/

Issue #19998 has been updated by byroot (Jean Boussier).

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. ---------------------------------------- Feature #19998: Emit deprecation warnings when the old (non-Typed) Data_XXX API is used https://bugs.ruby-lang.org/issues/19998#change-108696 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- The replacement API was introduced in Ruby 1.9.2 (2010) [Feature #3064], and the old untyped data API was marked a deprecated in the documentation as of Ruby 2.3.0 (2015): https://github.com/ruby/ruby/commit/98544c372d948717de22afc86d162e411f1fb5f1 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: - https://rubygems.org/gems/unf_ext (https://github.com/knu/ruby-unf_ext/pull/72) - https://rubygems.org/gems/rotoscope (https://github.com/Shopify/rotoscope/pull/99) - https://rubygems.org/gems/re2 (https://github.com/mudge/re2/pull/116) - ~~https://rubygems.org/gems/mysql2~~ (use either API to support old rubies) Migrating them over doesn't seem too hard. -- https://bugs.ruby-lang.org/