[swift-evolution] final + lazy + fileprivate modifiers

[Goffredo Marocchi]

Please, almost anything but going back to the horrible Objective-C pattern of private headers (that end up included on in the implementation files) :/.

Seriously, that was always my issue with that blog post, assuming that the Objective-C way of dealing with this issue was something worth moving forward and not a path to massively improve upon or to avoid.

Sent from my iPhone

> On 20 Feb 2017, at 08:30, Jonathan Hull via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Feb 19, 2017, at 7:29 PM, David Waite via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> A third point (which is a bit more complex/convoluted) is that fileprivate remained an essential language feature because it allows implementation in extensions, and allows a simple “friend”-like feature where types that need access to implementation details due to higher coupling could be bundled into the same file. Outside of a desire of a scoped ‘private’ simply to match the behavior of certain other languages, private is used to hide implementation details from other parts of a file, while file private exposes them within the file. 
>> 
>> There is a potential that file-private can lead to an explosion of complexity due to a large amount of “friendly types” being bundled into the same file. In that sense, ‘private’ was wrong because it was adding complexity at the file level, when really a new access level would possibly have been more productive to define at the at the small-group-of-files level - either via a friend access level or submodules. We still have the potential of unmanageable files due to friend types, but any additional access levels to aid with this problem would have to be weighed against a now significantly more complex access model including file and scoped private. In that sense, the inclusion of scoped private may indeed be harmful in that it increases the challenge of much more useful access levels being added to the language.
> 
> This is the core of what I have been saying.  If we don’t address this need of “friendly types” in a swift-y way, we will have to keep coming back to the drawing board (either for “friend” or “protected” or “submodules”).  I really like swift 2 private, but it did cause long files because all of the extensions and friends had to be stuck in the same file. What we are really missing is something that has the connotation similar to private, but allows access where needed.
> 
> I agree with most of what was said in this blog post from the swift devs:
> https://developer.apple.com/swift/blog/?id=11
> 
> The main exception is that I disagree that ‘internal’ maps to the ObjC case where a second header was used (it doesn’t, and that is what is causing all of this trouble).  Because internal is the default, it feels much too easy to accidentally use parts of a type which should only be used by extensions/subclasses/friend types. Remember, in an app (as opposed to a framework), internal is basically equivalent to public.  With the second header, users of the contents of that header had to explicitly include it, which meant there was no chance of accidental use.
> 
> What we need is something which maps to that second header case while still keeping everything conceptually simple and swift-y.
> 
> Thanks,
> Jon
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170220/362d11cf/attachment.html>