On 16.02.2017 10:14, Goffredo Marocchi via swift-evolution wrote:
I think it would be a step back as it again oversimplifies access control
IMHO. If we touch access control we should aim to improve it from both a
library implementation point of view but for a user point of view as well.
+1. I can't understand the opinion that we must to "simplify" but not
"improve". IMO access levels in languages like C# understandable by newbie
very well. IMO there is nothing hard(not more than concept of Optional or
generic type/protocol programming) to remember/understand 4-5 access
levels. Especially, if newbie can start programming even don't know about
access levels - as we have "internal" by default.
But these access levels adds a real value for the programmer, when he/she
can express intention better(even if there is just one coder!) and have
compiler support.
IMO we need the ability to say "in subtype or in extension in the same
*module*". Probably even just as "in the current file and in subtype or in
extension in the same *module*". I do think this solves the many questions
raised regarding limitations of current access modifiers.
Just as a variant:
* public -> outside of the module
* internal -> inside module
* private -> inside file
* protected(or other keyword) -> inside file + subtype&extensions in the
same module
IMO very clear model. "private" is something that is personal, hidden and
locked, nobody should touch this. "protected" - under protection, not for
public, but in some situations access can be granted. In this case we have
Swift2 simplicity of modifiers plus extra modifier that solves problems
with code distribution in files and with sharing implementation details for
subtypes/extensions in the same module. As I understand, no impact on ABI
as 'protected' just for internals of module. No?
Sent from my iPhone
On 16 Feb 2017, at 06:20, Chris Lattner via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Feb 14, 2017, at 11:46 PM, Jean-Daniel via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Keeping with the spirit of Swift and staying consistent with its
design, I see two plausible meanings for private:
Private could mean either:
...
(2) accessible only to the current type/scope and to extensions to
that type that are in the current file.
I think (2) is worth discussing. My 2 cents:
*Pros*
• Solves a high percentage of use cases of *fileprivate*
• Type-scope proponents retain some of the safety
*Cons*
• Less straight forward to explain
• Access to different type/scope in same file not possible anymore
Which means that if we choose 2, we must keep fileprivate.
Being able to access other type private members in the same file is an
important feature that can’t be easily replaced, so it would badely
break existing code if we remove it.
Yeah, I think you’re right, which sinks the whole idea: we should aim to
(re)simplify the access control model. (2) is also problematic because
it doesn’t allow the private members to be used by other things in the
same file. E.g. use a private member of Foo in an extension on String.
IMO, removing fileprivate and making private match Swift 2 semantics
seems like the more promising approach.
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
