[swift-evolution] In-line scope designators

[Robert Bennett]

+1 for member variables, -1 for member functions. Functions take up too much vertical space to make this convenient; you’d constantly be scrolling around to view or modify the access level of a function. Plus I tend to group functions by use — private functions go directly above the public function that calls them. But member declarations are often one or just a few lines, and additionally are often grouped by access level anyway (at least that’s how I do it) so this provides a compact way to group them.


> On Jun 17, 2017, at 5:48 PM, 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