A similar proposal can be found here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160613/020968.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160613/020968.html>
It uses a bit different syntax, but the gist of it seems the same to me... > On Jun 29, 2016, at 3:49 PM, Adrian Zubarev via swift-evolution > <[email protected]> wrote: > > 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<< > <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022511.html> > 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<< > <https://gist.github.com/DevAndArtist/c74f706febf93452999881335f6ca1f9>. > > 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] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
