[swift-evolution] final + lazy + fileprivate modifiers

[Ross O'Brien]

My two cents:

I like that Swift has a way of restricting access to some properties and
functions to just the scope in which they're declared (Swift 3 private).

At the moment I tend to use the Swift idiom of declaring a type, and then
declaring an extension each protocol conformance, and sometimes that means
putting a property in the type rather than the extension and that requires
fileprivate. That's not ideal, but if there were an idiomatically neater
way to declare a private property in the extension and have Swift recognise
that property as being part of the type but contextually linked only to
that protocol conformance then that would be good.

'Fileprivate' makes files equivalent to submodules, and this can lead to
undesirably long files. Possibly the dependence on filesystem structure
feels restrictive to some developers. It seems to me that in this four-tier
structure (public, internal, fileprivate, private) that a significant
number of developers think that's one, maybe two tiers too many (the system
should be simplified), and for others that's one, maybe two tiers too few
(fileprivate is doing too much, and a submodule tier would relieve that
pressure).

I think a submodule access level has been suggested a lot of times, but I
don't think anyone's formally proposed a possible syntax for it.

As Goffredo Marocchi said, I don't want to return to Objective C's dozen
import statements at the top of a file, but how would we denote that a file
is a member of a submodule? At the moment I think there are four ways -
have I missed any?

1) Submodules correspond directly to file directories (simple, but possibly
binds a project too closely to an operating system, inflexible for systems
like Git).
2) The submodule has an access control file which lists its member files
(as modules do)
3) Files opt-in to membership of a submodule (e.g. 'memberOf Submodule'
just below 'import Foundation')
4) Files 'friend' other files into their submodule, somehow.

Worth noting: the latter three of these suggestions don't implicitly
prevent a file from being a member of more than one submodule.

I don't have my own answer to this question yet, but I think discussion of
it will help decide whether submodules are a practical possibility. If they
are, perhaps there's justification for fileprivate; if not, perhaps
reverting to Swift 2's private is better.

Thanks,
Ross


On Mon, Feb 20, 2017 at 10:41 AM, Dimitri Racordon via swift-evolution <
swift-evolution at swift.org> wrote:

> I really don’t like the idea of an attritional access control file.
>
> Not everybody is using an IDE that automagically creates the structures
> and files for your favourite language, and I would hate to see Swift go the
> Java way where it’s impossible to build something seriously without Eclipse
> or Netbeans. Xcode is great, but I think we should not design Swift
> thinking it’s the norm to use it.
>
> I’d favourite any kind of syntax that is baked in the same file as the
> code.
>
> Thanks,
> Dimitri
>
> _______________________________________________
> 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/25a2670d/attachment.html>