> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor <[email protected] > <mailto:[email protected]>> wrote: > > >> On Apr 20, 2017, at 11:33 AM, Jordan Rose <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> This makes the private/fileprivate distinction meaningful for extensions. I >>> think also bans the use of "private" at global scope for non-nominal types >>> or extensions thereof. A clarifying update to the proposal is in order, so >>> developers can better understand the semantics. >> >> Wait, hang on, then people have to write 'fileprivate' instead of 'private' >> for top-level typealiases (and functions?). > > That seems like the correct behavior; private is about members with SE-0169. > What do you think? > > ...that seems suboptimal, given that the goal has been to make it possible > for people to use `private` more and not less frequently. IMO, there's no > need for `private typealias` at the global level to be prohibited.
Yeah, I see no reason for this to change the behavior of private extensions to be more restrictive than before. John. > > >> Apart from whether or not that's desirable, it's not backwards-compatible. > > Very true! It’s an easy thing to migrate, but it’s a source break > nonetheless. Let’s decide if it’s desirable and bring it up with the core > team. > > - Doug > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
