Dear Swift community, as most of you may know we’ve been discussing the future
of extintials and diverse design ideas. The result for Swift 3 is a proposal
which makes the first step by replacing procotol<A, B> with a new shorthand
syntax A & B.
The reason I’m posting this proposal so early is to get some feedback about
this idea in general. If the feedback is positive, I also would like some of
you to consider the removal of the access modifier from extensions. By that I
don’t mean to remove it completely. My honest opinion is that extensions should
have exactly the same access control like classes, enums and structs.
One take the access control from protocols and mix it with the access control
of classes (etc.) and the result is the access control for extensions. I just
can’t agree with the fact of laziness of typing out access modifier on
extension members some of you might have.
The current access control on extensions disallow us to use access modifier
when we involve protocol conformances.
Default implementations have three ways of declaring public visibility:
extension SomeProtocol {
public func someMember() {}
}
public extension SomeProtocol {
func someMember() {}
}
public extension SomeProtocol {
public func someMember() {}
}
If it was the access control mechanism for classes (etc.) there would be only a
single correct way to achieve this:
public class SomeClass {
public func someMember() {}
}
Feel free to join the conversation about removing the current behavior from
extensions for Swift 3. Here is the >>link<< to the last post. (I still have to
rewrite a few things to reflect my thoughts from the conversation.)
I’d like to introduce a new scoped but typeless mechanism to Swift (which might
be added after Swift 3 drops). I gave it a clean name group to showcase what it
will be used for. You can read my formatted draft >>here<<.
These were the basic ideas I had. I’ve already seen a few threads where some
people were asking for a way organizing variables into groups by an access
modifier. So here it is, but a group can solve other problems too. We could
finally stop abusing enums and also create access labels for a clear and swifty
code design.
The idea of groups is based on the access control of protocols. It would be
great if this mechanism could have its own scope, which then could be used
almost anywhere.
Detailed design
A group is typeless, and should be used for organization purposes.
Organizing members by an access modifier.
Providing an access label to type members (CamelCase).
Providing namespacing for API design (UpperCamelCase).
public group Reference {
/* implicitly public */ class String { ... }
/* implicitly public */ class Char { ... }
}
Possible usage:
let instance = Reference.String()
A group can be used inside any scope or at file level.
A group has one or no label at all:
A group without a label has always an explicit access modifier:
public struct A {
public group {
var a: Int { return self._a }
var aTimesTen: Int { return self.a * 10 }
}
internal group {
var _a: Int = 10
var _b: Int = 42
}
}
A group with a label has an optional access modifier:
Labeled groups without an access modifier are automatically internal.
Group members have the same access modifier as the group itself (like access
modifier on protocols).
Nested groups inherit the access modifier from its root group.
Labeled groups cannot be stored in any manner.
public class UIScrollView : ... {
public group {
/* implicitly public */ group content {
/* implicitly public */ var offset: CGPoint
/* implicitly public */ var size: CGSize
/* implicitly public */ var inset: UIEdgeInsets
}
/* implicitly public */ var someCoolPublicInteger: Int
}
...
}
Possible usage:
- scrollViewInstance.contentOffset
+ scrollViewInstance.content.offset
It should be possible to create multiple groups with the same/different access
modfier and the same acess label:
public struct B {
public group labelName {
var someVarName: Int
}
public group labelName {
var someOtherVarName: String
}
internal group labelName {
var _internalVarName: Double
}
}
It should be possible to extend existing labeled groups.
public struct C {
public group labelName {
var someVarName: Int
}
}
public extension C {
public group labelName {
var computedProperty: Int { ... }
}
}
Attributes aplied to a group will automatically be aplied to all members.
public class D {
public static group {
// public static var
var something: Int = 42
// public static func
func foo() { ... }
}
}
Grammar
declaration → group-declaration
group-declaration → attributesopt access-level-modifier group group-body
group-declaration → attributesopt access-level-modifieropt group group-name
group-body
group-name → identifier
group-body → { declarations }
--
Adrian Zubarev
Sent with Airmail
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
