@Daniel, agree. Sent from my iPhone. Erroneous words are a feature, not a typo.
> On 1 Dec 2016, at 14:23, Daniel Leping <[email protected]> wrote: > > Gonçalo, I can suggest a bit different API to avoid clashing. Something like: > > private (file, set) > > Instead of: > > private (file) (set) > > Looks easier to me as it poses a possibility just to list the attributes in a > pretty much standard way. > >> On Thu, 1 Dec 2016 at 16:15 Gonçalo Alvarez Peixoto via swift-evolution >> <[email protected]> wrote: >> @Daniel >> I am very fond of your idea, as I believe it add extra flexibility to this >> solution, as Álvaro mentioned. My only concern is somehow related to >> semantics. >> Should we add the extra scope detail as you suggest, then it could clash >> with the current way of setting a setter as private or fileprivate: >> >> Current: >> fileprivate(set) >> >> Suggested: >> private(file)(set) >> >> Still, of all the hurdles one might face, this one I believe is definitely >> the one that poses the less threat! >> >> @Tino >> As you imply on a previous email, this solution might even facilitate the >> introduction of new levels of access control all throughout modules, whether >> internally and externally. While I do agree complexity does raise an issue >> in designing a fine solution for access control, I insist this concern >> should not block the language's evolution into finer grained control and >> better focused levels of scope. Quoting Álvaro: "communication is something >> that everyone agrees is a essential in swift and access control is one of >> the many ways developers have to properly describe (and communicate) an API." >> >> Also Tino, you state: >> "The question for me is how much complexity should be accepted as a tradeoff >> for increased expressiveness? >> "private, internal, public" was quite simple, but the current system is >> already quite complicated, and it doesn't scale well." >> >> In fact, I consider this change a great opportunity for the current system >> to be revisited in a gradual manner. >> As to the equatable issue you pointed out, is there a reason why replacing >> the fileprivate access control level by with a typeprivate would not solve >> the problem raised with private? >> >> There's yet another issue I would like to reinforce, one raised on previous >> emails. As stated before, I do believe fileprivate, as a compiler related >> construct, opens the door for one to access members from another member, as >> long as they'r all sitting within the same file. This creates conditions for >> a odd and dangerous pattern. While I don't think fileprivate aims at >> promoting several type implementation within the same file, it certainly >> opens that door. That's one pattern a typeprivate access control level would >> grant no advantages in using. >> >> Best, >> Gonçalo >> _______________________________________________ >> 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
