> On Feb 20, 2017, at 3:43 AM, Ross O'Brien via swift-evolution
> <[email protected]> wrote:
>
> 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.
For #4, my suggestion has been to add a single keyword ‘hidden’. Marking
something hidden means that things outside of the file can’t see it.
public struct MyStruct {
var a:Int //This is ‘internal'
hidden var b:Int //This is also ‘internal’, but is hidden, so
is not visible outside the file
}
To let a file see the hidden items, you ‘import hidden’ instead of just
‘import’:
import hidden MyStruct //Now ‘b' is visible within this file
Because it is still internal, b is still only accessible within the module
(even with ‘import hidden’). If it was a ‘public hidden var’ or ‘open hidden
var’ then it could be accessed via ‘import hidden’ outside the module as well.
Make sense?
I think this is the simplest way to get behavior similar to protected, friends,
and submodules… all with swift’s file-based access approach.
Thanks,
Jon_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
