Hi Robert, This would be an optional feature, can be left out. if one doesn’t use it nothing changes. Although imho it looks better, the primary intent is to hide/protect members, be it vars, functions, from outside access, without having to type scope qualifiers on most of my source lines. As you can see, personally I use vertical space a lot: brackets on new lines, empty lines, etc. I use a Mac Mini with a a 4K screen and a relative small font (and reading glasses :o) thus having to scroll very little.
Kind Regards TedvG > On 19. Jun 2017, at 20:45, Robert Bennett <[email protected]> wrote: > > +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 >> <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
