I'm a little apprehensive about this pull request because it essentially defines another "scope" that you have to worry about. Crystal is (mostly) an object oriented language, and source files do not fit into the object hierarchy. It's a bit vague, but it doesn't "feel" right. I support private and protected types in the context of being private to the enclosing type, because then it allows you to extract file-private types into their own files without refactoring.

It is my opinion that instead of defining private classes, you should (currently, until private types) simply mark them as undocumented. In the stdlib where namespace pollution becomes an issue, I would just place them off the top level into the Crystal namespace. Plus, then the classes are available for people who really know what they're doing to use.

In short, I think that this issue is adequately solved by other means while being more friendly to refactoring, so doesn't warrant the extra effort to maintain another feature.

I want to check that this is not an issue.

public_foo.cr

class Foo
end

private_foo.cr

require "./public_foo"

private class Foo
end

foo = Foo.new # ok, this is the file private Foo.

# But, is there a way to reference the public Foo? Do we want it? 
# ::Foo won't work that well because we might need it to reference the private top level Foo
# from nested classes.

@bcardiff To reference the public Foo you can do ::Foo. With ::Name file-private types are never looked up.

private class Foo
end

class Bar
  class Foo
  end
  # Foo means Bar::Foo
  # ::Foo should mean the private foo IMO
  # hence the private ::Foo hides the public ::Foo 
end

I am ok with either this or what you just wrote. I just wanted to expose the scenario.

The scenarios I imagine I'd want to use a private type is when I want to declare a type and use it in that file only. In that case I can't imagine why I'd choose a name that would already conflict with other types I'm using in that file.

I agree :-) But i can't help myself

Having multiple classes with the same complete namespace, but different visibilities strikes me as totally confusing. If a public class ::Foo exists, then declaring a private ::Foo one should be an error IMO

@RX14 On the contrary, that's the whole point of private classes: I want to define a class in this file, and I don't want it to conflict in the future if someone defines a public one with that name. Giving an error in this case would basically make private types useless.

This is the same reason one uses private defs in a file: I want to declare a method and not letting anyone accidentally redefine it.

I'm a little puzzled on this feature. I can hardly find any usecase. I always use namespaces, so private types means I would need to create them outside of the namespace, at the top level, which seems wrong.

I would see use cases for protected types inside a namespace that would behave like methods: a compile time error when trying to reference them out of scope (ie. no shadowing).

two use cases are described in this thread: #3276 (comment). personally i think it is useful feature to have, but it would be nice if it could be used inside a namespace and behaved similar to private_constant from Ruby in that case.

I'm split on this issue. To me it also seems natural to make private types in a namespace, not at the top level. But then again, I don't have to use it.

@asterite, my point was that this feature is useless.

To clarify, this feature is confusing if you can define multiple seperate classes with the same name, and useless if you can't.

How are you doing to differentiate between two classes with the same name when debugging? You're also breaking the expectations set by almost every programming language that types have a unique name. It strikes me as a completely nonsensical tradeoff for something that should be - and already is - done using namespacing via modules.

@jazzonmymind Wow, thanks for commenting here! I did not know about Ruby's private_constant and I think that it's exactly what we should do. Ruby semantics are similar to what I described in #2950, and for now (and probably forever) we don't need to worry about protected types, maybe it doesn't make sense.

I'll soon update this PR with that addition. Private constants are very useful because they will make :nodoc: less needed. But I also think that file-private types are useful, for example in specs, and this behaviour would be consistent with file-private defs, so I'd like to introduce both changes at the same time.

Closed in favor of #3280