And another access control idea


(Manolo van Ee) #1

Hi All,

I’ve been following the access control discussion a little and I had an
idea that I wanted to throw out here. I know it’s too late and the idea
doesn’t provide source compatibility, but it seemed worthwhile to post it
anyway. My apologies if something similar has already been proposed.

First of all, I propose to use a trailing colon ‘:’ to make it clear that
it’s an access control keyword. Secondly, the idea introduces new keywords
that clearly describe the scope of access:

scope: (formerly private)
file: (formerly fileprivate)
module: (formerly internal, default)
extern: (formerly public)
extern(open): (formerly open)

Examples:

   1. extern: class SomePublicClass { // explicitly public class
   2. extern: var somePublicProperty = 0 // explicitly public class member
   3. var someInternalProperty = 0 // implicitly internal class member
   4. file: func someFilePrivateMethod() {} // explicitly file-private
   class member
   5. scope: func somePrivateMethod() {} // explicitly private class member
   6. }

   1. extern(open): class SomeOpenClass { // explicitly open class
   2.

   1. extern(open): func someOpenMethod() {} // explicitly open class member
   2. }

Having the keyword describe the access scope actually fits the access
control model of Swift very well. The user doesn’t have to learn what
public or private means, but only needs to know the concept. Especially
coming from another programming language I think public and private are
confusing and breaking with it will signal very clearly that the Swift
model is different.

The idea is source breaking, but it’s very easy to deprecate the current
syntax with a warning and automatically migrate, because:

   - All keywords are redefined, so there can be no confusion with the
   current syntax.
   - Only redefines the syntax, not the semantics.

Funny thing, I thought of this last night and when I woke up this morning I
read Erica’s proposal that uses many of the same keywords, although in a
different way. Telepathy? Or maybe we’re just onto something here?

I know this will turn everything upside down, but I like the overall
consistency, so I just wanted to throw it into the group as the next idea
to fix access controls and see if anyone likes it.

Alternatives considered:

   - ‘all’ instead of ‘extern’. This sounds to me as if it can always be
   accessed from everywhere, which might not be what we want if we introduce
   submodules.

Regards,
Manolo


(Brent Royal-Gordon) #2

Approaches like this were evaluated and rejected even before we introduced strict source stability requirements. `extern(open)` undoes an important feature of the `public`/`open` design, which is that there's no syntactic penalty for opening a symbol. And the SE-0169 acceptance specifically stated there would be no more access control changes in Swift 4.

I don't think this is a viable suggestion.

···

On Apr 15, 2017, at 2:01 AM, Manolo van Ee via swift-evolution <swift-evolution@swift.org> wrote:

Hi All,

I’ve been following the access control discussion a little and I had an idea that I wanted to throw out here. I know it’s too late and the idea doesn’t provide source compatibility, but it seemed worthwhile to post it anyway. My apologies if something similar has already been proposed.

First of all, I propose to use a trailing colon ‘:’ to make it clear that it’s an access control keyword. Secondly, the idea introduces new keywords that clearly describe the scope of access:

scope: (formerly private)
file: (formerly fileprivate)
module: (formerly internal, default)
extern: (formerly public)
extern(open): (formerly open)

Examples:
extern: class SomePublicClass { // explicitly public class
    extern: var somePublicProperty = 0 // explicitly public class member
    var someInternalProperty = 0 // implicitly internal class member
    file: func someFilePrivateMethod() {} // explicitly file-private class member
    scope: func somePrivateMethod() {} // explicitly private class member
}

extern(open): class SomeOpenClass { // explicitly open class
    extern(open): func someOpenMethod() {} // explicitly open class member
}

Having the keyword describe the access scope actually fits the access control model of Swift very well. The user doesn’t have to learn what public or private means, but only needs to know the concept. Especially coming from another programming language I think public and private are confusing and breaking with it will signal very clearly that the Swift model is different.

The idea is source breaking, but it’s very easy to deprecate the current syntax with a warning and automatically migrate, because:
All keywords are redefined, so there can be no confusion with the current syntax.
Only redefines the syntax, not the semantics.

Funny thing, I thought of this last night and when I woke up this morning I read Erica’s proposal that uses many of the same keywords, although in a different way. Telepathy? Or maybe we’re just onto something here?

I know this will turn everything upside down, but I like the overall consistency, so I just wanted to throw it into the group as the next idea to fix access controls and see if anyone likes it.

Alternatives considered:
‘all’ instead of ‘extern’. This sounds to me as if it can always be accessed from everywhere, which might not be what we want if we introduce submodules.

--
Brent Royal-Gordon
Architechies


(Manolo van Ee) #3

Hi All,

I’ve been following the access control discussion a little and I had an
idea that I wanted to throw out here. I know it’s too late and the idea
doesn’t provide source compatibility, but it seemed worthwhile to post it
anyway. My apologies if something similar has already been proposed.

First of all, I propose to use a trailing colon ‘:’ to make it clear that
it’s an access control keyword. Secondly, the idea introduces new keywords
that clearly describe the scope of access:

scope: (formerly private)
file: (formerly fileprivate)
module: (formerly internal, default)
extern: (formerly public)
extern(open): (formerly open)

Examples:

   1. extern: class SomePublicClass { // explicitly public class
   2. extern: var somePublicProperty = 0 // explicitly public class member
   3. var someInternalProperty = 0 // implicitly internal class member
   4. file: func someFilePrivateMethod() {} // explicitly file-private
   class member
   5. scope: func somePrivateMethod() {} // explicitly private class
   member
   6. }

   1. extern(open): class SomeOpenClass { // explicitly open class
   2.

   1. extern(open): func someOpenMethod() {} // explicitly open class
   member
   2. }

Having the keyword describe the access scope actually fits the access
control model of Swift very well. The user doesn’t have to learn what
public or private means, but only needs to know the concept. Especially
coming from another programming language I think public and private are
confusing and breaking with it will signal very clearly that the Swift
model is different.

The idea is source breaking, but it’s very easy to deprecate the current
syntax with a warning and automatically migrate, because:

   - All keywords are redefined, so there can be no confusion with the
   current syntax.
   - Only redefines the syntax, not the semantics.

Funny thing, I thought of this last night and when I woke up this morning
I read Erica’s proposal that uses many of the same keywords, although in a
different way. Telepathy? Or maybe we’re just onto something here?

I know this will turn everything upside down, but I like the overall
consistency, so I just wanted to throw it into the group as the next idea
to fix access controls and see if anyone likes it.

Alternatives considered:

   - ‘all’ instead of ‘extern’. This sounds to me as if it can always be
   accessed from everywhere, which might not be what we want if we introduce
   submodules.

Approaches like this were evaluated and rejected even before we introduced
strict source stability requirements. `extern(open)` undoes an important
feature of the `public`/`open` design, which is that there's no syntactic
penalty for opening a symbol. And the SE-0169 acceptance specifically
stated there would be no more access control changes in Swift 4.

I don't think this is a viable suggestion.

--
Brent Royal-Gordon

Architechies

I wasn't happy about 'extern(open)' either, but I liked the overall

consistency of the concept (at least for the other keywords) and hoped it
could be improved somehow.

Anyway, thanks for your response and sorry for the noise.

Regards,
Manolo

···

On Tue, 18 Apr 2017 at 04:56, Brent Royal-Gordon <brent@architechies.com> wrote:

On Apr 15, 2017, at 2:01 AM, Manolo van Ee via swift-evolution < > swift-evolution@swift.org> wrote: