Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

@Daniel, agree. Sent from my iPhone. Erroneous words are a feature, not a typo. > On 1 Dec 2016, at 14:23, Daniel Leping wrote: > > Gonçalo, I can suggest a bit different API to avoid clashing. Something like: > > private (file, set) > > Instead of: > > private

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

@Tino: Regarding the following statement - "Even if there was a change of mind, fileprivate is still needed for essential things like implementing Equatable.” How exactly is that so? Am I missing something? > > - Typeprivate would allow to abandon the odd fileprivate. Access level > > would be

[swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Definetely the access control topic is highly contestable in the Swift scene but nevertheless I really strive for more flexibility in terms of how can I decouple and decompose my code arch among several source files. As an example, I reckon that the current approach of attributing properties

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Still better than exposing to any subclass implementation or direct external access IMHO. Sent from my iPhone. Erroneous words are a feature, not a typo. > On 1 Dec 2016, at 07:40, Jean-Daniel wrote: > > If you add a typeprivate accessor, it means you expose your internal

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

Exactly. Totally agree Tino. Sent from my iPhone. Erroneous words are a feature, not a typo. > On 1 Dec 2016, at 09:31, Tino Heth <2...@gmx.de> wrote: > > >> It also means that anybody who want to access your private var will just >> have to write an extension to expose it. > imho this is