@Daniel, agree.

Sent from my iPhone. Erroneous words are a feature, not a typo.

> On 1 Dec 2016, at 14:23, Daniel Leping <dan...@crossroadlabs.xyz> 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 
>> <swift-evolution@swift.org> 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
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
swift-evolution mailing list

Reply via email to