Issue #17171 has been updated by jeremyevans0 (Jeremy Evans).


marcandre (Marc-Andre Lafortune) wrote in #note-7:
> So can we envision issuing a warning for two release cycles?
> 
> Is it feasible to issue a warning for constants that are currently public that would be made private this way?
> 
> Difficult being that call to `private_constant` happens after point of definition:
> 
> ```ruby
> class Foo
>   private
>   X = 42
> end # => Warn about privacy change
> 
> class Bar
>   private
>   X = 42
>   private_constant :X
> end # => No warning
> ```

I think if we do this, we should only warn on access (i.e. `Foo::X`), not definition.  This would require internal changes to add a sort of deprecated-public visibility.

----------------------------------------
Feature #17171: Why is the visibility of constants not affected by `private`?
https://bugs.ruby-lang.org/issues/17171#change-88030

* Author: marcandre (Marc-Andre Lafortune)
* Status: Open
* Priority: Normal
----------------------------------------
```ruby
class Foo
  def call_me
    # ...
  end

  private
 
  SOME_DATA = %i[...].freeze  # is public, why not private?

  def calc_stuff  # is private, ok.
    # ...
  end
end
```ruby

It's probably a naive question, but why shouldn't `SOME_DATA`'s visibility be private?

When writing gems, more often than not the constants that I write are not meant for public consumption. I find it redundant (and tiresome) to explicitly write `private_constant :SOME_DATA`.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>