[swift-evolution] In-line scope designators

[Tony Allevato]

You can already effectively have these "regions" using extensions, with the
exception of stored properties since they can't be placed there.

struct MyType { ... }
public extension MyType { ... }
private extension MyType { ... }

Once stored properties are allowed in extensions (IIRC supporting that
within the same file as the type declaration is something the core team has
said is reasonable?), you could do this there as well. Is this not
sufficient for what you want to do?

Since there are already two ways of specifying the visibility of a type
member (preceding the type itself, or using the default visibility of the
declaring extension), I'd be wary of adding a third.

On Mon, Jun 19, 2017 at 10:57 PM Rien via swift-evolution <
swift-evolution at swift.org> wrote:

> I don’t like this, it violates the locality principle. I.e. that all
> information that is needed to understand something is close by.
>
> But since it is not something that everybody has to use… I don’t object to
> it either.
>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift
>
>
>
>
>
>
>
> > On 17 Jun 2017, at 23:48, Ted F.A. van Gaalen via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > (I am not sure if I should tag this subject with [pitch]? )
> >
> > Please don’t worry , I am not attempting to start a new
> > and infinite thread about whether or not the way scope
> > is handled in Swift is imho correct or not.
> > Errhm well, apart from that “protected” is missing,
> > but please let us not start again.. :o)
> >
> > No, it is more or less a convenience solution to
> > prevent unnecessary wear and tear to the following keys
> > on my keyboard: [ A,E, I, P,  R, T, V]
> >
> > I prefer it, not to expose those class or struct members
> > which should not be accessible outside the class or struct
> >
> > Currently, to prevent access to private Items,
> > I have to type the word “private” too many times:
> >
> > class  House
> > {
> >         private var rooms = 5
> >       private var roofTiles = 11201
> >       private let paint =   UIColor.Blue;
> >         private var yearTax: Money = “323,56"
> >         private let garageVolume = 60.0
> >
> >         init(..) {.. }
> >
> >          private func calculateTax() {...}
> >
> >          public func roomsUnoccupied() -> Int {…}
> >
> >         func roofData(……) {…}
> >
> >          private func  a{…}
> > }
> >
> > To set the scope of a list of members I suggest the
> > “in-line scope modifiers”  (anyone with a better name for it?)
> >
> > For example if one has a source line containing the word
> > “private:” then all the following member declarations will
> > be “private” until another inline scope modifier is encountered
> > with one “default scope” to escape from it. like in the following
> example”
> >
> > The compiler can detect that it is an inline scope modifier, because it
> ends with a colon
> >
> > “Normal” scope modifiers, that is the ones which precede the member’s
> name
> > directly should imho not be allowed within such a scope block.
> > unless they would override for that specific item, but that looks ugly.
> >
> > getter & setters and init should appear in default scope
> > (or with no in-line scope modifiers)
> >
> > Inline scope modifiers can be specified as often as
> > desired and in arbitrary sequence.
> >
> >
> > class  House
> > {
> >          init(..) {.. }
> >     private:                                            // <——  In-line
> scope modifier all following declarations are private here.
> >             var rooms = 5
> >           var roofTiles = 11201
> >           let paint =   UIColor.Blue;
> >             var yearTax: Money = “323,56"
> >             func calculateTax() {…}
> >             func  a{…}
> >
> >       public:                                             // <——
> In-line scope modifier
> >          var garageVolume = 60.0
> >          func roomsUnoccupied() -> Int {…}
> >          func roofData(……) {…}
> >
> >       defaultscope:                                 // <—— Return to
> default scope (only needed when preceding inline scope modifiers are
> present. )
> >
> >           func sellHouse(buyer: CustomerID)
> > }
> >
> > See? looks a lot better, don’t you think so?
> > it also makes sources more readable because one can
> > now conveniently group items.
> >
> > 100% source compatible with whatever scope
> > mechanism now or in the future is or will be deployed.
> >
> >
> > (The idea is not exactly new, a similar construct is available in Object
> Pascal.)
> >
> > ?
> >
> > Kind Regards
> > TedvG
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170620/2b7ad574/attachment.html>