In-line scope designators

(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

+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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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: Balancingrock (Rien) · GitHub
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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Yeah, I think that really only made sense in the world of header files, where function declarations were only one line each.

Off the top of my head, I wouldn't oppose it for non-computed properties, though.

- Dave Sweeris

···

On Jun 19, 2017, at 11:45, Robert Bennett via swift-evolution <swift-evolution@swift.org> wrote:

+1 for member variables, -1 for member functions. Functions take up too much vertical space to make this convenient;

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 <rltbennett@icloud.com> 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 <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Wouldn't a load of restrictions make it more complex to implement? I would say that if the feature was to be implemented it should just work for everything; this makes it a lot simpler to implement and just leaves it up to developers to decide where it is most appropriate to use it.

After all, very simple computed properties, lazy values and other functions can be written on a single line if you really want to do it, so it seems like this feature would be just as useful for those as well.

I'd probably keep them limited to type declarations though; i.e- not in extensions, since they can already declare visibility (except extensions for conformance, which imply a visibility).

···

On 19 Jun 2017, at 21:40, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 19, 2017, at 11:45, Robert Bennett via swift-evolution <swift-evolution@swift.org> wrote:

+1 for member variables, -1 for member functions. Functions take up too much vertical space to make this convenient;

Yeah, I think that really only made sense in the world of header files, where function declarations were only one line each.

Off the top of my head, I wouldn't oppose it for non-computed properties, though.

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@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: Balancingrock (Rien) · GitHub
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@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Hi Tony
I don’t think so, then I would have to split my class up into extensions,
not really workable I’d say. it would be an optional feature anyway. so one can still build classes
like it is now, no problem.
I would like in-line scope designators *within* extensions as well.
Regards
TedvG.

more below inline

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.

I don’t like this, it violates the locality principle. I.e. that all information that is needed to understand something is close by.

     well, what then if you use parts of your program defined in other sources, protocols … etc. ?
met vriendelijke groeten
TedvG

···

On 20. Jun 2017, at 17:10, Tony Allevato <tony.allevato@gmail.com> wrote:
On Mon, Jun 19, 2017 at 10:57 PM Rien via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

But since it is not something that everybody has to use… I don’t object to it either.

Regards,
Rien

Site: http://balancingrock.nl <http://balancingrock.nl/&gt;
Blog: http://swiftrien.blogspot.com <http://swiftrien.blogspot.com/&gt;
Github: Balancingrock (Rien) · GitHub
Project: http://swiftfire.nl <Indobet - Tempat Daftar Login Rtp Slot Gacor Indonesia; - 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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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

I still think nested extensions would have been a good addition to the language: If we had those,

struct MyType {
  private {
    var myPrivateVar: Int?
    var anotherOne: String?
  }
}

would be a rather small piece of syntactic sugar...

Hi Tony
I don’t think so, then I would have to split my class up into extensions,
not really workable I’d say.

Why not?

What makes this workable:

struct MyType {
  internal:
    var
    var
    var
  public:
    func
    func
  private:
    func
    func
}

but this not workable?

struct MyType {
  var
  var
  var
}
public extension MyType {
  func
  func
}
private extension MyType {
  func
  func
}

I don't see what's so bad about the latter example. It's just a different
syntax for what you're asking to do, except that it's already in the
language.

it would be an optional feature anyway. so one can still build classes
like it is now, no problem.
I would like in-line scope designators *within* extensions as well.

Every optional feature proposed to be added to the language has costs
associated with it—design time, implementation time, cognitive load on
people learning the language—so what I'm trying to determine is benefits
this would add to justify that cost. Since this can effectively be achieved
today with extensions (again, with the exception of stored properties,
which should be fixed separately and then that exception goes away), I'm
curious about what you think is missing here.

···

On Tue, Jun 20, 2017 at 8:57 AM Ted F.A. van Gaalen <tedvgiosdev@gmail.com> wrote:

Regards
TedvG.

more below inline

On 20. Jun 2017, at 17:10, Tony Allevato <tony.allevato@gmail.com> wrote:

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@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.

     well, what then if you use parts of your program defined in other
sources, protocols … etc. ?
met vriendelijke groeten
TedvG

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: Balancingrock (Rien) · GitHub
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@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Hi Tony

Personally, I find my solution much better because everything
of a class struct definition stays together in one place,
instead of being scattered over multiple extensions, wich btw,
can be placed anywhere, that is, not necessarily within
the same source file.. (no doubt that is what some people are
going to do… Also, Imho, this is not the right purpose of extensions.
Extension are primary meant for users of classes/structs, clearly,
as the name implies, to extend these, while keeping the original
class/structs intact and hidden from those users, if desired.
So I’d would consider this being a bad bad programming practice, sorry.
Btw. I’d prefer subclassing instead of extensions, however
this is not possible with structs...

Costs? Of, course there are implications, but that is the consequence
with every change to a programming language, with all the aspects
you have described below.
However, this is not a source changing feature, which should be not so
difficult to implement, completely optional, and almost trivial to use also for starters.

TedvG

Hi Tony
I don’t think so, then I would have to split my class up into extensions,
not really workable I’d say.

Why not?

What makes this workable:

btw, internal: can be omitted here:

···

On 20. Jun 2017, at 18:06, Tony Allevato <tony.allevato@gmail.com> wrote:
On Tue, Jun 20, 2017 at 8:57 AM Ted F.A. van Gaalen <tedvgiosdev@gmail.com <mailto:tedvgiosdev@gmail.com>> wrote:
struct MyType {
  internal:
    var
    var
    var
  public:
    func
    func
  private:
    func
    func
}

but this not workable?

struct MyType {
  var
  var
  var
}
public extension MyType {
  func
  func
}
private extension MyType {
  func
  func
}

I don't see what's so bad about the latter example. It's just a different syntax for what you're asking to do, except that it's already in the language.

it would be an optional feature anyway. so one can still build classes
like it is now, no problem.
I would like in-line scope designators *within* extensions as well.

Every optional feature proposed to be added to the language has costs associated with it—design time, implementation time, cognitive load on people learning the language—so what I'm trying to determine is benefits this would add to justify that cost. Since this can effectively be achieved today with extensions (again, with the exception of stored properties, which should be fixed separately and then that exception goes away), I'm curious about what you think is missing here.

Regards
TedvG.

more below inline

On 20. Jun 2017, at 17:10, Tony Allevato <tony.allevato@gmail.com <mailto:tony.allevato@gmail.com>> wrote:

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@swift.org <mailto:swift-evolution@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.

     well, what then if you use parts of your program defined in other sources, protocols … etc. ?
met vriendelijke groeten
TedvG

But since it is not something that everybody has to use… I don’t object to it either.

Regards,
Rien

Site: http://balancingrock.nl <http://balancingrock.nl/&gt;
Blog: http://swiftrien.blogspot.com <http://swiftrien.blogspot.com/&gt;
Github: Balancingrock (Rien) · GitHub
Project: http://swiftfire.nl <Indobet - Tempat Daftar Login Rtp Slot Gacor Indonesia; - 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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Before bringing this forward, I’ve tried brackets { } as well
for “my feature” but found this to be a bit awkward,
confusing with real program { } blocks,
also because it has nothing to do with blocks
(except for the class or struct body as limitation)
rather its effect is sequential, line by line,
within the class or struct body.
e.g:
      default scope here.
  private:
       source lines
       all declarations in lines following are private
       until another in-line scope designator is encountered.
  defalutscope:
      source lines
   public:
      source lines
    end of class/ struct/

Thus, it acts more or less like a compiler directive…
therefore, perhaps this would better:

@private:
   source lines
@public:
   source lines
@defaultscope: // returns to default scope
  source lines.
  
?

TedvG

···

On 20. Jun 2017, at 18:32, Tino Heth <2th@gmx.de> wrote:

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

I still think nested extensions would have been a good addition to the language: If we had those,

struct MyType {
  private {
    var myPrivateVar: Int?
    var anotherOne: String?
  }
}

would be a rather small piece of syntactic sugar...