It might have been suggested (this discussion is huge), but I think private
could just be defined more or less like a combination of Swift 3 fileprivate
and private with one little twist - it is also accessible from extensions in
other files internal to the defining module.
Module 1 File A.swif
> On 21 Feb 2017, at 01:00, Xiaodi Wu via swift-evolution
> wrote:
>
> I'm terribly sorry to be _that guy_, but I have to interject that
> `private(file)` was discussed extensively during review for SE-0025, that the
> full scheme laid out in the first message of this thread was given
> cons
I'm terribly sorry to be _that guy_, but I have to interject that
`private(file)` was discussed extensively during review for SE-0025, that
the full scheme laid out in the first message of this thread was given
consideration, and that the core team took these suggestions into account
before accepti
> On 20 Feb 2017, at 15:25, Ross O'Brien wrote:
> Does 'private(module, type)' grant get-set access to external subclasses, or
> get-only?
Without a specific set condition it'd be both get and set for both. So you
might need to do for example:
private(module, set:type) func someMethod() { … }
>
>
> This is what I had in mind; i.e- you don't *have* to parameterise
> private, you'd only do it if you want something other than the default.
>
> As for something with both public and private modifiers (only really
> applies to properties I think?) I think it's fine to just declare each
> separ
> On 20 Feb 2017, at 12:27, Ross O'Brien wrote:
>
> Orthogonal extensions, such as 'protected', multiply the problem. How do you
> restrict which access levels get 'type' access?
Well, I was really just mentioning it as a future possibility, I hadn't quite
gotten as deciding exactly how type
> On 20 Feb 2017, at 13:30, Brent Royal-Gordon wrote:
>
>> On Feb 20, 2017, at 3:42 AM, Haravikk via swift-evolution
>> wrote:
>>
>> The proposal I preferred was to use only the public and private keywords and
>> use parameters to provide greater specificity, like so:
>>
>> public
> On Feb 20, 2017, at 3:42 AM, Haravikk via swift-evolution
> wrote:
>
> The proposal I preferred was to use only the public and private keywords and
> use parameters to provide greater specificity, like so:
>
> public as it is now
> private(module) equivalent to i
> Perhaps 'type' access is 'set' level unless explicitly exposed:
> private(get: file, set: scope, type: module)
In a word - Yikes! Why on earth do access modifiers have to be sooo complicated?
I have written absolutely massive frameworks in C# with nothing but :
public - Access is not restricte
Let's start with: I much prefer including the word 'file' in the file
access level, to not including it. The bikeshedding discussions proposed
too many permutations of 'public' 'external' 'internal' 'private' for me,
not to mention the potential additions of 'secret', 'hidden', 'closed'... I
think
So discussion of the exact naming convention for access modifiers has been
discussed multiple times, especially when fileprivate was being introduced.
It's now been a while since fileprivate was added, so we've all had more time
to actually work with it, so I wanted to raise the discussion again
11 matches
Mail list logo
