"The thing is, typeprivate cannot replace fileprivate, just because
fileprivate adds internal visibility to other scopes inside the same file
and does not restrict it to the same type. And I really love that aspect of
Swift. :)"

While I do see the advantages in exposing members within the same file, we
must agree that can promote somehow odd patterns of chunking code into the
same file. As I said before,  that's definitely not the intent, however
there's no mechanism of preventing it. I believe typeprivate would
definitely help in scoping and improving code readability while we're at it!

private       // like `private(scope)`
private(file) // like `internal(file)`
private(type) // in your case

I must say I am very fond of this solution as well. It clearly conveys the
idea.

"PS: I also cannot wait for existentials to drop typealias ProtoB =
Any<Proto> where Proto.A == B where B comes from a generic parameter list
and A is an associated type."
Same here!

Best,
Gonçalo


2016-12-02 11:58 GMT+00:00 Adrian Zubarev <[email protected]>:

> IMO there is no need for something like typepublic to even exist, but in
> theory it would be something like where a subclass has more visibility of
> the internal stuff of its super type. I’m just saying that someone will
> want this, because that person might thing that typepublic and typeprivate
> would be consistent.
>
> In general I’m for anything that adds flexibility, but flexibility means
> also more complexity.
>
> The thing is, typeprivate cannot replace fileprivate, just because
> fileprivate adds internal visibility to other scopes inside the same file
> and does not restrict it to the same type. And I really love that aspect of
> Swift. :)
>
> It already has been discussed thousands of times but I cannot resist and
> also state my preference to something like:
>
> private       // like `private(scope)`
> private(file) // like `internal(file)`
> private(type) // in your case
>
> ------------------------------
>
> This is a POP language right? So lets focus on fixing and improving
> protocols. :) We should start with open/public protocol.
> ------------------------------
>
> PS: I also cannot wait for existentials to drop typealias ProtoB =
> Any<Proto> where Proto.A == B where B comes from a generic parameter list
> and A is an associated type.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 2. Dezember 2016 um 12:36:45, Gonçalo Alvarez Peixoto (
> [email protected]) schrieb:
>
> Also, would you be so kind to provide an example where typepublic would be
> useful? Maybe you're thinking of allowing member access to subclasses?
> Would that fall into a possible "protected" realm?
>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to