Re: [swift-evolution] Simplifying Default Access Modifiers

[Xiaodi Wu via swift-evolution]

It bears mentioning that it does _not_ formally work this way with
fileprivate or private types. The default access level for members is
always internal. This was a deliberate change I suggested for SE-0025 and
is new for Swift 3. It's just also the case that the rules were relaxed to
allow you to mock up greater access for members than the containing type
(for instance, you can label members public inside a fileprivate type).

The suggestion of defaulting members to the access of the enclosing scope
was considered and rejected for the reasons enumerated already by others:
namely, that public members should always be explicitly annotated. This
becomes doubly important now that we have open as a full-fledged access
level. There is also the little problem that private in the enclosing scope
is not an utterable level in the enclosed scope, which is neatly obviated
by the fact that the default access level is internal.


On Mon, Feb 13, 2017 at 03:02 Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> I would like to propose a change to the default access modifier within an
> enclosing scope.  The default for top level definitions would stay
> internal, but anything within a scope would by default have the same
> visibility as it’s enclosing scope.
>
> The main reason for this is readability/maintainability, and having the
> intention clearly stand out.  It would also reduce a great amount of
> boilerplate.  It also matches the mental model of how scopes normally work
> regarding inheritance of visibility/properties (which means less to teach
> newbies).
>
> Right now if I want to make a type and all of it’s vars/methods public, I
> have to mark each individual var/method public, which leads to a lot of
> boilerplate/noise and makes everything harder to read:
>
> public struct MyStruct {
> public var a:Int
> public var b:Int
> private var c:Int
> public var d:Int
> }
>
> Notice that the private var doesn’t really stand out as such very well.
> Also, it is exceedingly rare (at least in my own coding style) that I
> actually want an internal variable unless the type itself is internal, and
> in those cases, I would like that choice to stand out as deliberate the
> same way I want ‘private' to stand out.  As it stands, I wait until I think
> I am done modifying a type to mark it public because of the extra noise
> generated.  I also make a point to write ‘internal' for things that I
> explicitly want to restrict to internal.
>
> Consider the alternative:
>
> public struct MyStruct {
> var a:Int
> var b:Int
> private var c:Int
> var d:Int
> }
>
> Now the fact that I have chosen to make ‘c’ private really stands out much
> better.  When revisiting the code in 6 months, the struct is much more
> “glance-able” (as a friend of mine likes to say).
>
> Note also the nuance that I didn’t say that those vars were marked public
> (or had the same modifier), I said that they had the SAME VISIBILITY as the
> enclosing scope (which in this case happens to be public).  This is a
> concept which is hard to express currently, and IIRC this is what we had to
> do to make the edge cases of swift 3’s private modifier work properly.
>
> Basically, it already works this way for ‘private’, ‘fileprivate’, &
> ‘internal’, just not for ‘public’ or ‘open’… which can be surprising,
> especially since you don’t discover these differences until you are working
> across modules.  We should just extend that mental model up to include
> public and open.  Migration would just take internal variables of
> public/open types and mark them explicitly with the word ‘internal'.
>
> Thanks,
> Jon
>
> ___
> 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

Re: [swift-evolution] Simplifying Access Using 'Hidden'

[Xiaodi Wu via swift-evolution]

Hasn't "hidden" already been discussed? I could swear that it was already
pitched and feedback given.

In any case there's an ongoing discussion in another thread about removing
new private; it seems distinctly poor form to abandon that and propose
doing the exact opposite (removing old private) in a new thread.


On Mon, Feb 13, 2017 at 08:06 Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> I wanted to propose a second simplification to the access system which
> would have several benefits:
>
> • It would remove ‘fileprivate’
> • It would allow extensions to be in their own files
> • It would serve the needs of ‘protected’ without the
> complications involved in that
> • It would serve some of the needs of submodules (but also work
> together with them really nicely when we have both)
> • It would allow protocols to have something similar to private
> methods, which are not exposed to callers of the protocol, but still
> required for conformance
>
>
> My proposal is to add a ‘hidden’ access modifier which would act as a
> separate AXIS as opposed to a new level.  Thus, it could be combined with
> any of the other modifiers (e.g. 'public hidden var’).  The ‘fileprivate’
> level would be removed.
>
> Anything which is marked hidden is not visible outside of the file it is
> defined in.  That visibility can be explicitly restored on a per file basis
> (but only within the defined access level). Take a look at the following:
>
> //File: MyStruct.swift
>
> struct MyStruct {
> var a:Int
> hidden var b:Int
> }
>
> extension MyStruct {
> var biggest:Int {return max(a,b)} //We can still see ‘b’
> because it is only hidden outside the file
> }
>
> Here we see that ‘b’ behaves very similarly to the way fileprivate works
> now.  ‘b’ is technically still internal, but it is hidden and thus can’t be
> seen outside the file.  The difference is that instead of being forced to
> add all of our extensions in the same file, we can organize them however we
> prefer.
>
> //In another file
> import hidden MyStruct //This exposes all ‘hidden’ items from the
> file MyStruct to this file
>
> extension MyStruct {
> var c:Int {return a + b} //We can see ‘b’ because of the
> ‘import hidden’ statement
> }
>
>
> Notice how the intent has been shown here.  ‘b’ is marked ‘internal’,
> which means we know that no one can see ‘b’ outside of the module.  In
> addition ‘b’ is marked ‘hidden’, which means that the author is saying that
> this should only really be accessed from extensions, subclasses, or types
> which would be called friends in other languages.  The actual guarantee is
> still ‘internal’, but a caller does have to explicitly request the access
> by typing ‘import hidden’, which will stop accidental/casual misuse.
> (If/when we get submodules, then we can make tighter guarantees)
>
> This also allows a class to “hide the ejection seat levers” from its
> callers, while still allowing access for subclasses and extensions (i.e. it
> does most of what ‘protected’ would do, but with swift’s simpler file-based
> access model)
>
> The same is true of protocols.  There are often methods I have to include
> on protocols which are needed by the default implementations, but NEVER
> meant to be called directly by callers of the protocol.  If vars/methods of
> a protocol are marked hidden, then they would be hidden from callers of the
> protocol outside the file.  They are still required for conformance,
> however*.
>
> protocol MyProtocol {
> var a:Int
> hidden var b:Int  //Conformers still need to provide this,
> but callers can’t see it
> }
>
> extension MyProtocol {
> func doSomethingBasedOnB() {
> //The extension can see b in the same file, but
> callers in other files won’t have access to ‘b’ directly
> }
> }
>
> I think all of this works really well with Swift’s goal of progressive
> disclosure.  Users of protocols/classes/etc… are not exposed to the
> internals necessary for extension (e.g. it won’t come up in autocomplete)
> until they actually need to conform/subclass/extend.  Users won’t even need
> to learn about ‘hidden' until they are trying to extend a type which uses
> it (in a way which requires access to those internals), or they are writing
> their own framework.  It has a simple and consistent meaning based on
> Swift’s original file-based access, but allows power/flexibility (without
> too much bookkeeping/boilerplate) where needed.
>
> Thanks,
> Jon
>
>
> * One detail needed to make things useful for protocols, is that both
> hidden and non-hidden vars/methods on the conforming type should count
> towards conformance of hidden vars/methods on the protocol.  Basically,
> marking something as ‘hidden’ on 

Re: [swift-evolution] Why doesn't Collection's SubSequence conform to Collection?

[Max Moiseev via swift-evolution]

Because it would be recursive. which is not supported, I believe.


protocol Foo {
associatedtype Bar : Foo
}

Playground execution failed: error: MyPlayground.playground:2:20: error: type 
may not reference itself as a requirement
associatedtype Bar : Foo
   ^

> On Feb 13, 2017, at 1:42 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> The following comment accompanies the declaration of the SubSequence 
> associated type in the Collection protocol:
> 
> /// A sequence that represents a contiguous subrange of the collection's
> /// elements.
> ///
> /// This associated type appears as a requirement in the `Sequence`
> /// protocol, but it is restated here with stricter constraints. In a
> /// collection, the subsequence should also conform to `Collection`.
> associatedtype SubSequence : IndexableBase, Sequence = Slice
> 
> The comments clearly state that the subsequence should conform to Collection, 
> however, it is not declared as such. Why is this?
> 
> Charles
> 
> ___
> 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

[swift-evolution] Why doesn't Collection's SubSequence conform to Collection?

[Charles Srstka via swift-evolution]

The following comment accompanies the declaration of the SubSequence associated 
type in the Collection protocol:

/// A sequence that represents a contiguous subrange of the collection's
/// elements.
///
/// This associated type appears as a requirement in the `Sequence`
/// protocol, but it is restated here with stricter constraints. In a
/// collection, the subsequence should also conform to `Collection`.
associatedtype SubSequence : IndexableBase, Sequence = Slice

The comments clearly state that the subsequence should conform to Collection, 
however, it is not declared as such. Why is this?

Charles

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

Re: [swift-evolution] Simplifying Access Using 'Hidden'

[Joanna Carter via swift-evolution]

What still strikes me as odd is that we now seem to have a plethora of 
visibilities, some of which do not provide for a given context, some of which 
seem to be looking for a context to justify their existence.

Whatever it is called, I find the idea of a file scope visibility somewhat 
bizarre and at odds with the principle of standard OO class encapsulation.

The two main reasons I can see for the perceived need for fileprivate are :

1. being able to separate out "sections" of a class into various extensions

2. giving global junkies the ability to write all their code in one unit

Surely, there are members of a type that the writer wants to remain private, 
even if an extension were declared in the same file. Fine, we have private for 
that and, even if the writer declares members to be fileprivate, there is no 
way that any extension declared outside of the file can see those members.

Now, I have a problem with that. If I want to access non-public members when I 
extend a type, either I declare those extensions in the same unit and declare 
those members as fileprivate, or if I want to declare those extensions in 
another file, I have to move up to the next suitable scope, which is internal.

But internal is too "open" because it allows, not only my chosen extensions to 
see those members but, also, any other code in the entire module.

Having made use of the "friend" concept in C++, this "all or next to nothing" 
approach to visibility seems to leave me in much the same place as Objective-C, 
where I could only have private or public, unless I did some tricky stuff with 
class extensions, something which really didn't look that pretty.

There are some parts of a type that I would want to remain really, really 
private to the type, not even visible to an extension.

There are other parts of a type that I would want to be private to that type 
but also visible in, but only in, extensions explicitly written against that 
type.

Which is why I am suggesting the "extensible" scope : private to the declaring 
type but also and only visible within any extension to that type.

Here follows a highly contrived example :

// Person.swift
public struct Person
{
  public var name: String
  
  public extensible(set) var dateOfBirth: Date
  
  public var age: Int
  {
// return calculated age as of today
  }

  init(name: String, dateOfBirth: Date)
  {
self.name = name

self.dateOfBirth = dateOfBirth // accessible as if it were private
}

// Registrar.swift
extension Person
{
  func correct(dateOfBirth: Date)
  {
self.dateOfBirth = …
  }
}

// Test.swift
{
  let person = Person()
  
  person.dateOfBirth = … // compilation error, not visible
}

IMHO, this then removes one use case for fileprivate in that it allows 
privileged visibility to private members of a type in extensions, both in the 
same file and in any other file. But, it also ensures that not other code is 
allowed access, whether that be in non-extension code in the same file or other 
non-extension code anywhere else.

As for case 2. for fileprivate, if a developer wants to put all sorts of 
globals and other code in one file, then I doubt if they are even going to 
bother to use fileprivate, especially when they get internal visibility with 
less typing ;)

Now, if someone could help me prepare this as a proposal…

--
Joanna Carter
Carter Consulting

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

Re: [swift-evolution] Simplifying Default Access Modifiers

[Xiaodi Wu via swift-evolution]

The purpose of an implicit internal, at least a big one, is for progressive
disclosure. It allows learners to write useful types (and indeed entire
apps) before they learn about access levels. Of the existing access levels
only internal fits the bill.

I do agree that for optimal style internal should be written out; indeed I
write out the access level for each member. I really don't see a need to
force everyone to adopt that style though, as long as we have one
consistent rule for what the default is.


On Mon, Feb 13, 2017 at 07:38 Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:

> On 13 Feb 2017, at 14:24, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> –1 for me.
>
> IMO the current behavior reduces all that internal noise in large
> projects, where the author only makes a small part of the API public.
> Furthermore this will break the implicit initializer on structs and make it
> implicitly public. Leaving the initializer as internal while everything
> else is public as a workaround would be inconsistent solution, so that’s
> a no go. Personally I think that will introduce more noise than the current
> behavior, because we’ll have to repeat internal all over the place in
> large projects. So in my eyes this would be a regression.
>
> P.S.: I’m curious what the core team has to say about this.
>
> I actually think “internal” is something which is worth calling out
> explicitly. It says that something is visible to other types in the project
> but not generally exported as part of the library’s API, which isn’t
> necessarily obvious. Implicit initialisers can be defined as having the
> same visibility as the type which they initialise.
>
> Would be a huge source-breaking change though. I’m not sure anybody’s
> really 100% happy with our access modifiers, but it’s such a big change the
> core-team would understandably be reluctant to do it.
>
> - Karl
>
>
> ___
> 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

Re: [swift-evolution] Simplifying Access Using 'Hidden'

[Goffredo Marocchi via swift-evolution]

A battle shout of "you will need language lawyers to decide all we are building 
to avoid protected" ;)?

Sent from my iPhone

> On 13 Feb 2017, at 23:38, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> The beauty of Swift 2's access modifiers was that they were based around 
> files and modules, explicitly rejecting types and scopes as units for 
> determining visibility. It seems at base there's a group of people who reject 
> that decision altogether. Hence, new `private`, proposals around `protected`, 
> `friend`, `hidden`, `extensible`, etc.
> 
> The point of the other thread was that a sizable proportion of people are 
> finding the old system to be elegant and a suitable basis for future 
> enhancements such as submodules. Here, there's another proportion of people 
> who want to dismantle the old design completely. This was pitched already 
> during the Swift 3 evolution process, repeatedly.
> 
> At some point, we've got to stop relitigating this design. It's untenable to 
> have something as foundational as access control change with every version of 
> Swift.
> 
> My two cents are that supporting all the shades of private is completely a 
> non-goal. I've yet to be convinced that more access modifiers will improve 
> anyone's code sufficiently to justify any more turmoil in the language. The 
> Swift 2 way took a very pragmatic approach. When can I access this member? If 
> private: when I have the source code already open; if internal: when I have 
> the source code available to open; if public: whenever. It takes the 
> opinionated (but IMO correct) view that it's not particularly useful for the 
> compiler to hide something from you that you can plainly see and touch.
> 
> 
>> On Mon, Feb 13, 2017 at 5:04 PM, Joanna Carter via swift-evolution 
>>  wrote:
>> What still strikes me as odd is that we now seem to have a plethora of 
>> visibilities, some of which do not provide for a given context, some of 
>> which seem to be looking for a context to justify their existence.
>> 
>> Whatever it is called, I find the idea of a file scope visibility somewhat 
>> bizarre and at odds with the principle of standard OO class encapsulation.
>> 
>> The two main reasons I can see for the perceived need for fileprivate are :
>> 
>> 1. being able to separate out "sections" of a class into various extensions
>> 
>> 2. giving global junkies the ability to write all their code in one unit
>> 
>> Surely, there are members of a type that the writer wants to remain private, 
>> even if an extension were declared in the same file. Fine, we have private 
>> for that and, even if the writer declares members to be fileprivate, there 
>> is no way that any extension declared outside of the file can see those 
>> members.
>> 
>> Now, I have a problem with that. If I want to access non-public members when 
>> I extend a type, either I declare those extensions in the same unit and 
>> declare those members as fileprivate, or if I want to declare those 
>> extensions in another file, I have to move up to the next suitable scope, 
>> which is internal.
>> 
>> But internal is too "open" because it allows, not only my chosen extensions 
>> to see those members but, also, any other code in the entire module.
>> 
>> Having made use of the "friend" concept in C++, this "all or next to 
>> nothing" approach to visibility seems to leave me in much the same place as 
>> Objective-C, where I could only have private or public, unless I did some 
>> tricky stuff with class extensions, something which really didn't look that 
>> pretty.
>> 
>> There are some parts of a type that I would want to remain really, really 
>> private to the type, not even visible to an extension.
>> 
>> There are other parts of a type that I would want to be private to that type 
>> but also visible in, but only in, extensions explicitly written against that 
>> type.
>> 
>> Which is why I am suggesting the "extensible" scope : private to the 
>> declaring type but also and only visible within any extension to that type.
>> 
>> Here follows a highly contrived example :
>> 
>> // Person.swift
>> public struct Person
>> {
>>   public var name: String
>> 
>>   public extensible(set) var dateOfBirth: Date
>> 
>>   public var age: Int
>>   {
>> // return calculated age as of today
>>   }
>> 
>>   init(name: String, dateOfBirth: Date)
>>   {
>> self.name = name
>> 
>> self.dateOfBirth = dateOfBirth // accessible as if it were private
>> }
>> 
>> // Registrar.swift
>> extension Person
>> {
>>   func correct(dateOfBirth: Date)
>>   {
>> self.dateOfBirth = …
>>   }
>> }
>> 
>> // Test.swift
>> {
>>   let person = Person()
>> 
>>   person.dateOfBirth = … // compilation error, not visible
>> }
>> 
>> IMHO, this then removes one use case for fileprivate in that it allows 
>> privileged visibility to private members of a type in extensions, both in 
>> the same file and in any other file. But, it also 

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Brent Royal-Gordon via swift-evolution]

> On Feb 13, 2017, at 8:14 AM, Adrian Zubarev  
> wrote:
> 
> Is that assumption correct?
> 
> // Module A
> public protocol SQLiteValue {
> init(statement: SQLiteStatement, columnAt index: Int) throws
> func bind(to statement: SQLiteStatement, at index: Int) throws
> }
> 
> // Module B
> protocol SQLiteLoggable : SQLiteValue {
> var logDescription: String { get }
> }
> 
> I could not follow your example there. If SQLiteLoggable is from module B 
> than this should be an error in my opinion. Otherwise open would have less 
> meaning on protocols, because you always could create an empty protocol that 
> has a super public protocol which you’re not allowed to conform to in module 
> B. This would be a silly workaround to being able to conform to it 
> SQLiteValue indirectly without any further requirement like in 
> SQLiteValueConvertible.

The idea is that a type in Module B could not conform to `SQLiteLoggable` 
without also having a valid conformance to `SQLiteValue`—either by taking a 
type Module A conforms to `SQLValue` and retroactively conforming it to 
`SQLiteLoggable`, or by adding a conformance to `SQLiteConvertible` in Module 
B. So this would not be allow you to work around `SQLiteValue`'s non-open-ness.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Simplifying Access Using 'Hidden'

[Xiaodi Wu via swift-evolution]

The beauty of Swift 2's access modifiers was that they were based around
files and modules, explicitly rejecting types and scopes as units for
determining visibility. It seems at base there's a group of people who
reject that decision altogether. Hence, new `private`, proposals around
`protected`, `friend`, `hidden`, `extensible`, etc.

The point of the other thread was that a sizable proportion of people are
finding the old system to be elegant and a suitable basis for future
enhancements such as submodules. Here, there's another proportion of people
who want to dismantle the old design completely. This was pitched already
during the Swift 3 evolution process, repeatedly.

At some point, we've got to stop relitigating this design. It's untenable
to have something as foundational as access control change with every
version of Swift.

My two cents are that supporting all the shades of private is completely a
non-goal. I've yet to be convinced that more access modifiers will improve
anyone's code sufficiently to justify any more turmoil in the language. The
Swift 2 way took a very pragmatic approach. When can I access this member?
If private: when I have the source code already open; if internal: when I
have the source code available to open; if public: whenever. It takes the
opinionated (but IMO correct) view that it's not particularly useful for
the compiler to hide something from you that you can plainly see and touch.


On Mon, Feb 13, 2017 at 5:04 PM, Joanna Carter via swift-evolution <
swift-evolution@swift.org> wrote:

> What still strikes me as odd is that we now seem to have a plethora of
> visibilities, some of which do not provide for a given context, some of
> which seem to be looking for a context to justify their existence.
>
> Whatever it is called, I find the idea of a file scope visibility somewhat
> bizarre and at odds with the principle of standard OO class encapsulation.
>
> The two main reasons I can see for the perceived need for fileprivate are :
>
> 1. being able to separate out "sections" of a class into various extensions
>
> 2. giving global junkies the ability to write all their code in one unit
>
> Surely, there are members of a type that the writer wants to remain
> private, even if an extension were declared in the same file. Fine, we have
> private for that and, even if the writer declares members to be
> fileprivate, there is no way that any extension declared outside of the
> file can see those members.
>
> Now, I have a problem with that. If I want to access non-public members
> when I extend a type, either I declare those extensions in the same unit
> and declare those members as fileprivate, or if I want to declare those
> extensions in another file, I have to move up to the next suitable scope,
> which is internal.
>
> But internal is too "open" because it allows, not only my chosen
> extensions to see those members but, also, any other code in the entire
> module.
>
> Having made use of the "friend" concept in C++, this "all or next to
> nothing" approach to visibility seems to leave me in much the same place as
> Objective-C, where I could only have private or public, unless I did some
> tricky stuff with class extensions, something which really didn't look that
> pretty.
>
> There are some parts of a type that I would want to remain really, really
> private to the type, not even visible to an extension.
>
> There are other parts of a type that I would want to be private to that
> type but also visible in, but only in, extensions explicitly written
> against that type.
>
> Which is why I am suggesting the "extensible" scope : private to the
> declaring type but also and only visible within any extension to that type.
>
> Here follows a highly contrived example :
>
> // Person.swift
> public struct Person
> {
>   public var name: String
>
>   public extensible(set) var dateOfBirth: Date
>
>   public var age: Int
>   {
> // return calculated age as of today
>   }
>
>   init(name: String, dateOfBirth: Date)
>   {
> self.name = name
>
> self.dateOfBirth = dateOfBirth // accessible as if it were private
> }
>
> // Registrar.swift
> extension Person
> {
>   func correct(dateOfBirth: Date)
>   {
> self.dateOfBirth = …
>   }
> }
>
> // Test.swift
> {
>   let person = Person()
>
>   person.dateOfBirth = … // compilation error, not visible
> }
>
> IMHO, this then removes one use case for fileprivate in that it allows
> privileged visibility to private members of a type in extensions, both in
> the same file and in any other file. But, it also ensures that not other
> code is allowed access, whether that be in non-extension code in the same
> file or other non-extension code anywhere else.
>
> As for case 2. for fileprivate, if a developer wants to put all sorts of
> globals and other code in one file, then I doubt if they are even going to
> bother to use fileprivate, especially when they get internal visibility
> with less typing ;)
>
> Now, if someone could 

Re: [swift-evolution] [Pitch] Int / Int returns Quotient-Remainder Tuple

[Timothy Wood via swift-evolution]

> On Feb 13, 2017, at 4:03 PM, Dan Stenmark via swift-evolution 
>  wrote:
> 
> 
> let (quotient, remainder) = 17 / 5
> print( "Q:\(quotient) R:\(remainder)" )// Idiot-proof!


This would seem pretty reasonable to me if instead of a tuple, it returned a 
Rational struct where Int(_ rational: Rational) would do what “17 / 5” does 
right now. In this case you could have the hint provided by the extra “Int(…)” 
and an error if you missed it, but with less verbiage. The compiler could (in 
theory) skip the remainder calculation if you never accessed the remainder.

-tim

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

Re: [swift-evolution] [Pitch] Int / Int returns Quotient-Remainder Tuple

[Max Moiseev via swift-evolution]

FWIW the new integers proposal defines a quotientAndRemainder method for 
FixedWidthInteger protocol:
https://github.com/apple/swift-evolution/pull/598/files#diff-6ef84b28f2eaeb383265ccbb60650022R785
 


This is not the default you’re proposing, however...

Max

> On Feb 13, 2017, at 4:03 PM, Dan Stenmark via swift-evolution 
>  wrote:
> 
> (I get the feeling the response to this pitch will be overwhelming negative, 
> but *deep inhale* here I go!)
> 
> A common mistake I see programmers make is dividing two integers and 
> expecting a floating-point result.  This mostly affect new programmers who 
> haven't learned about ALUs yet, but I sometimes even see veterans make the 
> mistake when they don't realize that neither operand they're passing is 
> floating-point.
> 
> let foo = 17 / 5
> print( foo )// Huh, why is this 3 and not 3.4?  Oh, wait, I'm an idiot.
> 
> I'd like to propose we make '/' operator on two Ints return a 
> quotient-remainder tuple by default.  This should help both new and veteran 
> programmers alike write less error-prone code.
> 
> let (quotient, remainder) = 17 / 5
> print( "Q:\(quotient) R:\(remainder)" )// Idiot-proof!
> 
> Thoughts?
> 
> Dan
> ___
> 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

Re: [swift-evolution] Why doesn't Collection's SubSequence conform to Collection?

[Douglas Gregor via swift-evolution]

> On Feb 13, 2017, at 1:42 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> The following comment accompanies the declaration of the SubSequence 
> associated type in the Collection protocol:
> 
> /// A sequence that represents a contiguous subrange of the collection's
> /// elements.
> ///
> /// This associated type appears as a requirement in the `Sequence`
> /// protocol, but it is restated here with stricter constraints. In a
> /// collection, the subsequence should also conform to `Collection`.
> associatedtype SubSequence : IndexableBase, Sequence = Slice
> 
> The comments clearly state that the subsequence should conform to Collection, 
> however, it is not declared as such. Why is this?

The compiler doesn’t support “recursive” constraints. We’re working on it

https://gist.github.com/DougGregor/e7c4e7bb4465d6f5fa2b59be72dbdba6 



- Doug


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

Re: [swift-evolution] Why doesn't Collection's SubSequence conform to Collection?

[Huon Wilson via swift-evolution]

The lines just after the current declaration show the desired version, which is 
waiting on two generics features that are in the pipeline:

  // FIXME(ABI)#98 (Recursive Protocol Constraints):
  // FIXME(ABI)#99 (Associated Types with where clauses):
  // associatedtype SubSequence : Collection
  //   where
  //   Iterator.Element == SubSequence.Iterator.Element,
  //   SubSequence.Index == Index,
  //   SubSequence.Indices == Indices,
  //   SubSequence.SubSequence == SubSequence
  //
  // (> Implement recursive 
protocol
  // constraints)
  //
  // These constraints allow processing collections in generic code by
  // repeatedly slicing them in a loop.

Huon

> On Feb 13, 2017, at 13:42, Charles Srstka via swift-evolution 
>  wrote:
> 
> The following comment accompanies the declaration of the SubSequence 
> associated type in the Collection protocol:
> 
> /// A sequence that represents a contiguous subrange of the collection's
> /// elements.
> ///
> /// This associated type appears as a requirement in the `Sequence`
> /// protocol, but it is restated here with stricter constraints. In a
> /// collection, the subsequence should also conform to `Collection`.
> associatedtype SubSequence : IndexableBase, Sequence = Slice
> 
> The comments clearly state that the subsequence should conform to Collection, 
> however, it is not declared as such. Why is this?
> 
> Charles
> 
> ___
> 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

[swift-evolution] [Pitch] Bridging nil to Objective-C Primitives

[Jeff Kelley via swift-evolution]

Hi all,

I don’t have a formal proposal written up yet, but in my continued quest to
make better-annotated Objective-C code, I had an idea for bridging nil with
primitives. Since in Objective-C we often use constant values to represent
invalid values or nil, the most obvious being NSNotFound, could we use that
as a shorthand for nil? Something like this for NSArray:

- (NSUInteger NS_SWIFT_NIL(NSNotFound))indexOfObject:(ObjectType)anObject;

This is a little verbose, so it could also work with a typedef:

typedef NSUInteger NS_SWIFT_NIL(NSNotFound) NSArrayIndex;
- (NSArrayIndex)indexOfObject:(ObjectType)anObject;

This would change the existing Swift interface to return an Int? instead of
an Int. I see this as working both ways—converting these values to nil when
returning from Objective-C to Swift, and sending these values instead of nil
when Swift calls into Objective-C code.

Is this worth writing up a proposal for? Is another, better method already
in someone’s mind?


Jeff Kelley

slauncha...@gmail.com | @SlaunchaMan  |
jeffkelley.org
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] Int / Int returns Quotient-Remainder Tuple

[Dan Stenmark via swift-evolution]

(I get the feeling the response to this pitch will be overwhelming negative, 
but *deep inhale* here I go!)

A common mistake I see programmers make is dividing two integers and expecting 
a floating-point result.  This mostly affect new programmers who haven't 
learned about ALUs yet, but I sometimes even see veterans make the mistake when 
they don't realize that neither operand they're passing is floating-point.

let foo = 17 / 5
print( foo )// Huh, why is this 3 and not 3.4?  Oh, wait, I'm an idiot.

I'd like to propose we make '/' operator on two Ints return a 
quotient-remainder tuple by default.  This should help both new and veteran 
programmers alike write less error-prone code.

let (quotient, remainder) = 17 / 5
print( "Q:\(quotient) R:\(remainder)" )// Idiot-proof!

Thoughts?

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

Re: [swift-evolution] Simplifying Access Using 'Hidden'

[Jonathan Hull via swift-evolution]

I think you hit the nail on the head in that the main issue is that our access 
control is mixing together several concepts (file-based, type-based, 
module-based, “open”).

I don’t think anyone is actually reading the proposal though.  Hidden is file 
based (not type based). It provides the functionality of protected, but using 
swift’s file based approach.  The reason ‘fileprivate’ goes away is not because 
it isn’t possible, but because it is essentially redundant (with the shorter 
keyword of ‘hidden’).

The big difference is that you can put extensions in separate files within the 
module (while still expressing intent).  Which based on your assertion that 
"it's not particularly useful for the compiler to hide something from you that 
you can plainly see and touch” is a good thing.

Also note that my proposal is completely compatible with either the Swift 2 or 
Swift 3 version of private. It does need one of them to stay, but either would 
work fine. As you say, having several shades of private is not helpful. 

Without something like this, we are going to continue to see a proliferation of 
new levels/proposals (e.g. friend & protected), each with associated 
bookkeeping/boilerplate.  The idea is to head that off and provide a single 
concept with enough flexibility to avoid that while still using Swift’s file 
based approach.

Thanks,
Jon


> On Feb 13, 2017, at 3:38 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> The beauty of Swift 2's access modifiers was that they were based around 
> files and modules, explicitly rejecting types and scopes as units for 
> determining visibility. It seems at base there's a group of people who reject 
> that decision altogether. Hence, new `private`, proposals around `protected`, 
> `friend`, `hidden`, `extensible`, etc.
> 
> The point of the other thread was that a sizable proportion of people are 
> finding the old system to be elegant and a suitable basis for future 
> enhancements such as submodules. Here, there's another proportion of people 
> who want to dismantle the old design completely. This was pitched already 
> during the Swift 3 evolution process, repeatedly.
> 
> At some point, we've got to stop relitigating this design. It's untenable to 
> have something as foundational as access control change with every version of 
> Swift.
> 
> My two cents are that supporting all the shades of private is completely a 
> non-goal. I've yet to be convinced that more access modifiers will improve 
> anyone's code sufficiently to justify any more turmoil in the language. The 
> Swift 2 way took a very pragmatic approach. When can I access this member? If 
> private: when I have the source code already open; if internal: when I have 
> the source code available to open; if public: whenever. It takes the 
> opinionated (but IMO correct) view that it's not particularly useful for the 
> compiler to hide something from you that you can plainly see and touch.
> 
> 
> On Mon, Feb 13, 2017 at 5:04 PM, Joanna Carter via swift-evolution 
> > wrote:
> What still strikes me as odd is that we now seem to have a plethora of 
> visibilities, some of which do not provide for a given context, some of which 
> seem to be looking for a context to justify their existence.
> 
> Whatever it is called, I find the idea of a file scope visibility somewhat 
> bizarre and at odds with the principle of standard OO class encapsulation.
> 
> The two main reasons I can see for the perceived need for fileprivate are :
> 
> 1. being able to separate out "sections" of a class into various extensions
> 
> 2. giving global junkies the ability to write all their code in one unit
> 
> Surely, there are members of a type that the writer wants to remain private, 
> even if an extension were declared in the same file. Fine, we have private 
> for that and, even if the writer declares members to be fileprivate, there is 
> no way that any extension declared outside of the file can see those members.
> 
> Now, I have a problem with that. If I want to access non-public members when 
> I extend a type, either I declare those extensions in the same unit and 
> declare those members as fileprivate, or if I want to declare those 
> extensions in another file, I have to move up to the next suitable scope, 
> which is internal.
> 
> But internal is too "open" because it allows, not only my chosen extensions 
> to see those members but, also, any other code in the entire module.
> 
> Having made use of the "friend" concept in C++, this "all or next to nothing" 
> approach to visibility seems to leave me in much the same place as 
> Objective-C, where I could only have private or public, unless I did some 
> tricky stuff with class extensions, something which really didn't look that 
> pretty.
> 
> There are some parts of a type that I would want to remain really, really 
> private to the type, not even visible to an 

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Goffredo Marocchi via swift-evolution]

I personally think that removing file private by itself does not solve the 
issue. We either put it all up for change (permissions levels and axis 
systems... including unsubclassable outside the module by default, warnings 
about overriding a default method only define in the protocol) and we look at a 
holistic situation admitting that what we have is not perfect or we just risk 
damaging the language over religious fronts that each declare to be Swiftier 
than the other. 

We cannot just address every bit of things with a very specific and restrictive 
language feature unless we want to go to the C++ language lawyers land for real.

Sent from my iPhone

> On 14 Feb 2017, at 07:08, David Hart via swift-evolution 
>  wrote:
> 
> 
>> On 14 Feb 2017, at 07:06, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Feb 12, 2017, at 12:35 PM, Xiaodi Wu  wrote:
>>> 
>>> _Potentially_ meaningful, certainly. But what I'm hearing is that it isn't 
>>> actually meaningful.
>> 
>> Yes, for sure.  That was carefully worded :-)
>> 
>>> Here's why:
>>> 
>>> If I see `fileprivate` and can understand that to mean "gee, the author 
>>> _designed_ this member to be visible elsewhere inside the file," then it's 
>>> actually meaningful. OTOH, if I see `fileprivate` and can only deduce "gee, 
>>> the author mashed some button in his or her IDE," then it's not really 
>>> telling me anything.
>>> 
>>> What you've said above, as I understand it, is that it's not currently 
>>> meaningful to see `fileprivate` because the migrator is writing it and not 
>>> the author. The improved approach you proposed is the additional warning. 
>>> In that case, the compiler will help to ensure that when I see 
>>> `fileprivate`, at least I know it's necessary. But that's only telling me a 
>>> fact (this member is accessed at least once outside the private scope), but 
>>> it's still machine-based bookkeeping, not authorial intent.
>> 
>> I see what you’re saying, but from a mechanical perspective, I disagree: 
>> seeing fileprivate in this (theoretical) world would be more meaningful than 
>> seeing private, because you know that there must be something in an 
>> extension that uses the member.
>> 
>> That said, whether it is meaningful or not is really not the question.  
>> Assuming you agree that it would carry “some” meaning, the question is 
>> really whether or not that meaning carries its own weight in terms of 
>> complexity in the language footprint.  I tend to think “no”.
>> 
>> If you agree with “no", then Swift 4.x should eradicate fileprivate as a 
>> concept and that we should revert SE-0025 from Swift 4 mode.  What to do 
>> with Swift 3.x still hangs in the balance of course.
> 
> Wouldn't 3.x mode just warn of the future deprecation?
> 
> Xiaodi: I'd be very tempted to write a proposal myself to revert SE-0025. But 
> it's going to be unpopular and I don't feel like I have the same ease as you 
> do to make the necessary points eloquently to convince as many people as 
> possible. Do you have the time to write it? If not, I'd really appreciate 
> some input from you: your points in this and the other thread have always 
> matched mine but were much better expressed :)
> 
>> -Chris 
>> 
>> ___
>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Simplifying Default Access Modifiers

[Charlie Monroe via swift-evolution]

-1. Aside from everyone being used to current behavior that I personally do 
find more logical since it prevents you from accidently exposing internal 
members via public API, the migrator won't have a choice but to slap "internal" 
everywhere during migration and like there are now projects full of 
"fileprivate", there will be projects full of "internal".

> On Feb 13, 2017, at 10:02 AM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> I would like to propose a change to the default access modifier within an 
> enclosing scope.  The default for top level definitions would stay internal, 
> but anything within a scope would by default have the same visibility as it’s 
> enclosing scope.
> 
> The main reason for this is readability/maintainability, and having the 
> intention clearly stand out.  It would also reduce a great amount of 
> boilerplate.  It also matches the mental model of how scopes normally work 
> regarding inheritance of visibility/properties (which means less to teach 
> newbies).
> 
> Right now if I want to make a type and all of it’s vars/methods public, I 
> have to mark each individual var/method public, which leads to a lot of 
> boilerplate/noise and makes everything harder to read:
> 
>   public struct MyStruct {
>   public var a:Int
>   public var b:Int
>   private var c:Int
>   public var d:Int
>   }
> 
> Notice that the private var doesn’t really stand out as such very well.  
> Also, it is exceedingly rare (at least in my own coding style) that I 
> actually want an internal variable unless the type itself is internal, and in 
> those cases, I would like that choice to stand out as deliberate the same way 
> I want ‘private' to stand out.  As it stands, I wait until I think I am done 
> modifying a type to mark it public because of the extra noise generated.  I 
> also make a point to write ‘internal' for things that I explicitly want to 
> restrict to internal.
> 
> Consider the alternative:
> 
>   public struct MyStruct {
>   var a:Int
>   var b:Int
>   private var c:Int
>   var d:Int
>   }
> 
> Now the fact that I have chosen to make ‘c’ private really stands out much 
> better.  When revisiting the code in 6 months, the struct is much more 
> “glance-able” (as a friend of mine likes to say).
> 
> Note also the nuance that I didn’t say that those vars were marked public (or 
> had the same modifier), I said that they had the SAME VISIBILITY as the 
> enclosing scope (which in this case happens to be public).  This is a concept 
> which is hard to express currently, and IIRC this is what we had to do to 
> make the edge cases of swift 3’s private modifier work properly.  
> 
> Basically, it already works this way for ‘private’, ‘fileprivate’, & 
> ‘internal’, just not for ‘public’ or ‘open’… which can be surprising, 
> especially since you don’t discover these differences until you are working 
> across modules.  We should just extend that mental model up to include public 
> and open.  Migration would just take internal variables of public/open types 
> and mark them explicitly with the word ‘internal'.
> 
> Thanks,
> Jon
> 
> ___
> 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

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Slava Pestov via swift-evolution]

> On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution 
>  wrote:
> 
> I was reading this nice listing of Swift keywords 
> (https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh
>  
> )
>  and three of them struck me as potentially not long for this world and I was 
> thinking if we needed/could deprecate them before any kind of ABI stability 
> set in.
> 
> I'm listing them here but it might be worth starting separate discussions for 
> each of them.
> 
> Final
> 
> Can someone tell me what is the use of 'final' now that we have 'public' 
> default to disallowing subclassing in importing modules? I know that 'final' 
> has the added constraint of disallowing subclassing in the same module, but 
> how useful is that? Does it hold its weight? Would we add it now if it did 
> not exist?

Adding or removing ‘final’ on a non-open class, or members of a non-open class, 
will not change ABI.

Slava

> 
> Lazy
> 
> This one is clearer: if Joe Groff's property behaviors proposal from last 
> year is brought forward again, lazy can be demoted from a language keyword to 
> a Standard Library property behavior. If Joe or anybody from the core team 
> sees this: do we have any luck of having this awesome feature we 
> discussed/designed/implemented in the Swift 4 timeframe?
> 
> Fileprivate 
> 
> I started the discussion early during the Swift 4 timeframe that I regret the 
> change in Swift 3 which introduced a scoped private keyword. For me, it's not 
> worth the increase in complexity in access modifiers. I was very happy with 
> the file-scope of Swift pre-3. When discussing that, Chris Latner mentioned 
> we'd have to wait for Phase 2 to re-discuss it and also show proof that 
> people mostly used 'fileprivate' and not the new 'private' modifier as proof 
> if we want the proposal to have any weight. Does anybody have a good idea for 
> compiling stats from GitHub on this subject? First of all, I've always found 
> the GitHub Search quite bad and don't know how much it can be trusted. 
> Secondly, because 'private' in Swift 2 and 3 have different meanings, a 
> simple textual search might get us wrong results if we don't find a way to 
> filter on Swift 3 code.
> 
> Thanks for hearing me out!
> 
> David.
> ___
> 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

Re: [swift-evolution] [Pitch] Bridging nil to Objective-C Primitives

[Rod Brown via swift-evolution]

I think the biggest problem we're going to face with this one is changes to 
Objective-C are out of scope for Swift Evolution. Apple tend to be the ones in 
control of the development of new Objective-C features and compatibility 
because they control the compiler.

That said, as a request to Apple for this change, I think it's a reasonable 
idea for Ints, but I'm not sure of its feasibility for other types. Could the 
API be descriptive enough to cover enough types? (Eg CGRectNull)


> On 14 Feb 2017, at 2:33 pm, Jeff Kelley via swift-evolution 
>  wrote:
> 
> Hi all,
> 
>   I don’t have a formal proposal written up yet, but in my continued 
> quest to make better-annotated Objective-C code, I had an idea for bridging 
> nil with primitives. Since in Objective-C we often use constant values to 
> represent invalid values or nil, the most obvious being NSNotFound, could we 
> use that as a shorthand for nil? Something like this for NSArray:
> 
> - (NSUInteger NS_SWIFT_NIL(NSNotFound))indexOfObject:(ObjectType)anObject;
> 
>   This is a little verbose, so it could also work with a typedef:
> 
> typedef NSUInteger NS_SWIFT_NIL(NSNotFound) NSArrayIndex;
> - (NSArrayIndex)indexOfObject:(ObjectType)anObject;
> 
>   This would change the existing Swift interface to return an Int? 
> instead of an Int. I see this as working both ways—converting these values to 
> nil when returning from Objective-C to Swift, and sending these values 
> instead of nil when Swift calls into Objective-C code.
> 
>   Is this worth writing up a proposal for? Is another, better method 
> already in someone’s mind?
> 
> 
> Jeff Kelley
> 
> slauncha...@gmail.com | @SlaunchaMan | jeffkelley.org
> ___
> 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

Re: [swift-evolution] final + lazy + fileprivate modifiers

[David Hart via swift-evolution]

> On 14 Feb 2017, at 07:06, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Feb 12, 2017, at 12:35 PM, Xiaodi Wu  wrote:
>> 
>> _Potentially_ meaningful, certainly. But what I'm hearing is that it isn't 
>> actually meaningful.
> 
> Yes, for sure.  That was carefully worded :-)
> 
>> Here's why:
>> 
>> If I see `fileprivate` and can understand that to mean "gee, the author 
>> _designed_ this member to be visible elsewhere inside the file," then it's 
>> actually meaningful. OTOH, if I see `fileprivate` and can only deduce "gee, 
>> the author mashed some button in his or her IDE," then it's not really 
>> telling me anything.
>> 
>> What you've said above, as I understand it, is that it's not currently 
>> meaningful to see `fileprivate` because the migrator is writing it and not 
>> the author. The improved approach you proposed is the additional warning. In 
>> that case, the compiler will help to ensure that when I see `fileprivate`, 
>> at least I know it's necessary. But that's only telling me a fact (this 
>> member is accessed at least once outside the private scope), but it's still 
>> machine-based bookkeeping, not authorial intent.
> 
> I see what you’re saying, but from a mechanical perspective, I disagree: 
> seeing fileprivate in this (theoretical) world would be more meaningful than 
> seeing private, because you know that there must be something in an extension 
> that uses the member.
> 
> That said, whether it is meaningful or not is really not the question.  
> Assuming you agree that it would carry “some” meaning, the question is really 
> whether or not that meaning carries its own weight in terms of complexity in 
> the language footprint.  I tend to think “no”.
> 
> If you agree with “no", then Swift 4.x should eradicate fileprivate as a 
> concept and that we should revert SE-0025 from Swift 4 mode.  What to do with 
> Swift 3.x still hangs in the balance of course.

Wouldn't 3.x mode just warn of the future deprecation?

Xiaodi: I'd be very tempted to write a proposal myself to revert SE-0025. But 
it's going to be unpopular and I don't feel like I have the same ease as you do 
to make the necessary points eloquently to convince as many people as possible. 
Do you have the time to write it? If not, I'd really appreciate some input from 
you: your points in this and the other thread have always matched mine but were 
much better expressed :)

> -Chris 
> 
> ___
> 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

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Chris Lattner via swift-evolution]

> On Feb 12, 2017, at 12:35 PM, Xiaodi Wu  wrote:
> 
> _Potentially_ meaningful, certainly. But what I'm hearing is that it isn't 
> actually meaningful.

Yes, for sure.  That was carefully worded :-)

> Here's why:
> 
> If I see `fileprivate` and can understand that to mean "gee, the author 
> _designed_ this member to be visible elsewhere inside the file," then it's 
> actually meaningful. OTOH, if I see `fileprivate` and can only deduce "gee, 
> the author mashed some button in his or her IDE," then it's not really 
> telling me anything.
> 
> What you've said above, as I understand it, is that it's not currently 
> meaningful to see `fileprivate` because the migrator is writing it and not 
> the author. The improved approach you proposed is the additional warning. In 
> that case, the compiler will help to ensure that when I see `fileprivate`, at 
> least I know it's necessary. But that's only telling me a fact (this member 
> is accessed at least once outside the private scope), but it's still 
> machine-based bookkeeping, not authorial intent.

I see what you’re saying, but from a mechanical perspective, I disagree: seeing 
fileprivate in this (theoretical) world would be more meaningful than seeing 
private, because you know that there must be something in an extension that 
uses the member.

That said, whether it is meaningful or not is really not the question.  
Assuming you agree that it would carry “some” meaning, the question is really 
whether or not that meaning carries its own weight in terms of complexity in 
the language footprint.  I tend to think “no”.

If you agree with “no", then Swift 4.x should eradicate fileprivate as a 
concept and that we should revert SE-0025 from Swift 4 mode.  What to do with 
Swift 3.x still hangs in the balance of course.

-Chris 

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

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Chris Lattner via swift-evolution]

> On Feb 12, 2017, at 10:14 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> FWIW, you're not the first to propose these names. `public(open)` was 
> suggested during the `open` debate and rejected in favor of `open`. 
> `private(file)` was suggested during the `fileprivate` debate and rejected in 
> favor of `fileprivate`. `protected` and `abstract` have been suggested on 
> this list multiple times.

Yes, these proposals are not going to happen IMO.  I don’t speak for the core 
team, but we should be aiming to *reduce* complexity in the access control 
space (even at the cost of expressivity) — not increase it.

-Chris


> 
> 
> On Mon, Feb 13, 2017 at 12:04 AM, Vanderlei Martinelli via swift-evolution 
> > wrote:
> Some corrections and additions to my previous email:
> 
> public(open)  // if open is absent, the method is “closed”
> protected // (yes, we and Cocoa still use classes)
> internal
> private(file) // if file is absent, the method is really, really private
> ​
> And one observation: protected and abstract as described before: only to be 
> valid for classes, of course. Something like local access modifier for local 
> only scope would be nice too (and does not break anything written until 
> today).
> 
> —
> Vanderlei Martinelli
> 
> ___
> 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

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

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Adrian Zubarev via swift-evolution]

I actually made a small visual of how open vs. public should work constantly on 
twitter: https://twitter.com/DevAndArtist/status/829688528216924160




-- 
Adrian Zubarev
Sent with Airmail

Am 13. Februar 2017 um 15:20:10, Matthew Johnson via swift-evolution 
(swift-evolution@swift.org) schrieb:



Sent from my iPad

> On Feb 13, 2017, at 1:35 AM, Rien via swift-evolution 
>  wrote:
>  
>  
>> On 13 Feb 2017, at 06:16, Derrick Ho via swift-evolution 
>>  wrote:
>>  
>> I think I we can live with the original three: public, internal, and private
>>  
>> Where public is visible to all,
>> Internal is visible to all within the module, and private is visible only to 
>> the class and the same file.
>>  
>> We can still fulfill the same roles that the current five fill.
>>  
>> Open can become public again.
>> Public can become final public

This is incorrect. The way `public` behaves today is very different than `final 
public`. Today it only restricts clients of a library from subclassing the 
class. `final public` also prevents the library itself from doing this not only 
in future versions, but also in the current version. This is very useful 
behavior that is not available if we adopt your suggestion.

>> Internal remains the same
>> Fileprivate assimilates into private
>>  
>> Make access control simple again!
>  
> Agree.
>  
> To me this discussion exemplifies the “square peg in a round hole” problem.
> None of these (fileprivate & open) keywords add information to a source code. 
> They do add noise however.
>  
> The difference between fileprivate and private is only of importance to a 
> group development effort. And then it is used for internal communication 
> within that group, never to the outside world. In a way “private” tells other 
> group members that they should ask the original developer why he choose 
> private instead of fileprivate. (And more than often be told “just change it”)
> This is something that would be better solved by comments imo.

This is not true at all. I have found the distinction useful both in personal 
projects and in a team environment.

>  
> Open vs public is less obvious as there seems to be a use case for this. 
> However in the end it only “forces” an API user to wrap the “public” 
> interface so he can then use it again as “open”.
> Hence it does not solve a design problem, it only leads to a cumbersome 
> interface.

Composition is often a better approach than inheritance. Allowing a library to 
expose classes publicly is very valuable. It allows them the ability to design 
classes that are not intended to be subclasses and have that intent verified by 
the compiler. Supporting subclassing correctly is difficult and not always 
appropriate.

>  
>  
> Now, if we really want to add information to the source code, then we would 
> do away with the restriction approach entirely and adopt an access list 
> approach. I.e. it would be possible to specify for each interface element 
> which other module/file has access to it.

A long list of access specifications does not lend itself to clarity or 
conciseness. While it is more specific, it is also far more difficult to 
comprehend. Swift strikes a pretty good balance of control, clarity of intent 
and conciseness IMO, but ultimately this is a judgement call.

>  
> Regards,
> Rien
>  
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
>>  
>  
>> On Sun, Feb 12, 2017 at 9:42 PM Xiaodi Wu via swift-evolution 
>>  wrote:
>> On Sun, Feb 12, 2017 at 8:37 PM, Dietmar Planitzer  wrote:
>> I know that private was scoped to files before Swift 3.
>>  
>> Fileprivate should obviously be removed because it is, like I said 
>> previously, just a poor man’s package access level. Yes, private was scoped 
>> to a file before Swift 3, but at least there wasn’t two kinds of private for 
>> a single file. Also scoping private to a file makes sense in Swift because 
>> it plays well with the ability to organize the implementation of a type 
>> inside of a file into the base type and a number of extensions. I now have 
>> to use fileprivate in Swift 3 to pull this off while there isn’t a 
>> requirement for a separate private access level. The fileprivate / private 
>> distinction also needlessly gets in the way when you want to refactor an 
>> existing type implementation into base type + extensions, all living in the 
>> same file.
>>  
>> Anyway, I don’t see a good reason why we should end up with this, once 
>> sub-modules exist:
>>  
>> open, public, module, fileprivate, private
>>  
>> when we can live with this:
>>  
>> open, public, module, private
>>  
>> and we’re not losing anything that would be significant compared to the 
>> alternative scenario.
>>  
>> Well, there's also internal: open, public, internal, (submodule, however it 
>> 

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Tino Heth via swift-evolution]

Imho the only good "excuse" for "new private" are playgrounds.
They are often forgotten in discussions, but afaics, Swift aims to be a good 
language for teaching, so there is some impact on its design.

Of course, this is only speculation on motivation, as I wasn't involved in the 
decision to add any Playground-related features to Swift (or other features ;-)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] final + lazy + fileprivate modifiers

[David Hart via swift-evolution]

Very good graphic. But it reinforces my opinion that it's currently more 
messy/complicated than I should be. It looks like an over-designed or 
designed-by-comitee model. I understand that private is useful, but not useful 
enough to warrant the increased complexity. My 2 cents.

> On 13 Feb 2017, at 15:25, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I actually made a small visual of how open vs. public should work constantly 
> on twitter: https://twitter.com/DevAndArtist/status/829688528216924160
> 
>  
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 13. Februar 2017 um 15:20:10, Matthew Johnson via swift-evolution 
> (swift-evolution@swift.org) schrieb:
> 
>> 
>> 
>> Sent from my iPad
>> 
>> > On Feb 13, 2017, at 1:35 AM, Rien via swift-evolution 
>> >  wrote:
>> > 
>> > 
>> >> On 13 Feb 2017, at 06:16, Derrick Ho via swift-evolution 
>> >>  wrote:
>> >> 
>> >> I think I we can live with the original three: public, internal, and 
>> >> private
>> >> 
>> >> Where public is visible to all,
>> >> Internal is visible to all within the module, and private is visible only 
>> >> to the class and the same file.
>> >> 
>> >> We can still fulfill the same roles that the current five fill.
>> >> 
>> >> Open can become public again.
>> >> Public can become final public
>> 
>> This is incorrect. The way `public` behaves today is very different than 
>> `final public`. Today it only restricts clients of a library from 
>> subclassing the class. `final public` also prevents the library itself from 
>> doing this not only in future versions, but also in the current version. 
>> This is very useful behavior that is not available if we adopt your 
>> suggestion.
>> 
>> >> Internal remains the same
>> >> Fileprivate assimilates into private
>> >> 
>> >> Make access control simple again!
>> > 
>> > Agree.
>> > 
>> > To me this discussion exemplifies the “square peg in a round hole” problem.
>> > None of these (fileprivate & open) keywords add information to a source 
>> > code. They do add noise however.
>> > 
>> > The difference between fileprivate and private is only of importance to a 
>> > group development effort. And then it is used for internal communication 
>> > within that group, never to the outside world. In a way “private” tells 
>> > other group members that they should ask the original developer why he 
>> > choose private instead of fileprivate. (And more than often be told “just 
>> > change it”)
>> > This is something that would be better solved by comments imo.
>> 
>> This is not true at all. I have found the distinction useful both in 
>> personal projects and in a team environment.
>> 
>> > 
>> > Open vs public is less obvious as there seems to be a use case for this. 
>> > However in the end it only “forces” an API user to wrap the “public” 
>> > interface so he can then use it again as “open”.
>> > Hence it does not solve a design problem, it only leads to a cumbersome 
>> > interface.
>> 
>> Composition is often a better approach than inheritance. Allowing a library 
>> to expose classes publicly is very valuable. It allows them the ability to 
>> design classes that are not intended to be subclasses and have that intent 
>> verified by the compiler. Supporting subclassing correctly is difficult and 
>> not always appropriate.
>> 
>> > 
>> > 
>> > Now, if we really want to add information to the source code, then we 
>> > would do away with the restriction approach entirely and adopt an access 
>> > list approach. I.e. it would be possible to specify for each interface 
>> > element which other module/file has access to it.
>> 
>> A long list of access specifications does not lend itself to clarity or 
>> conciseness. While it is more specific, it is also far more difficult to 
>> comprehend. Swift strikes a pretty good balance of control, clarity of 
>> intent and conciseness IMO, but ultimately this is a judgement call.
>> 
>> > 
>> > Regards,
>> > Rien
>> > 
>> > Site: http://balancingrock.nl
>> > Blog: http://swiftrien.blogspot.com
>> > Github: http://github.com/Balancingrock
>> > Project: http://swiftfire.nl
>> >> 
>> > 
>> >> On Sun, Feb 12, 2017 at 9:42 PM Xiaodi Wu via swift-evolution 
>> >>  wrote:
>> >> On Sun, Feb 12, 2017 at 8:37 PM, Dietmar Planitzer  
>> >> wrote:
>> >> I know that private was scoped to files before Swift 3.
>> >> 
>> >> Fileprivate should obviously be removed because it is, like I said 
>> >> previously, just a poor man’s package access level. Yes, private was 
>> >> scoped to a file before Swift 3, but at least there wasn’t two kinds of 
>> >> private for a single file. Also scoping private to a file makes sense in 
>> >> Swift because it plays well with the ability to organize the 
>> >> implementation of a type inside of a file into the base type and a number 
>> >> of extensions. I now have to use fileprivate in Swift 3 

Re: [swift-evolution] Simplifying Default Access Modifiers

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Feb 13, 2017, at 3:02 AM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> I would like to propose a change to the default access modifier within an 
> enclosing scope.  The default for top level definitions would stay internal, 
> but anything within a scope would by default have the same visibility as it’s 
> enclosing scope.
> 
> The main reason for this is readability/maintainability, and having the 
> intention clearly stand out.  It would also reduce a great amount of 
> boilerplate.  It also matches the mental model of how scopes normally work 
> regarding inheritance of visibility/properties (which means less to teach 
> newbies).
> 
> Right now if I want to make a type and all of it’s vars/methods public, I 
> have to mark each individual var/method public, which leads to a lot of 
> boilerplate/noise and makes everything harder to read:
> 
>public struct MyStruct {
>public var a:Int
>public var b:Int
>private var c:Int
>public var d:Int
>}
> 
> Notice that the private var doesn’t really stand out as such very well.  
> Also, it is exceedingly rare (at least in my own coding style) that I 
> actually want an internal variable unless the type itself is internal, and in 
> those cases, I would like that choice to stand out as deliberate the same way 
> I want ‘private' to stand out.  As it stands, I wait until I think I am done 
> modifying a type to mark it public because of the extra noise generated.  I 
> also make a point to write ‘internal' for things that I explicitly want to 
> restrict to internal.
> 
> Consider the alternative:
> 
>public struct MyStruct {
>var a:Int
>var b:Int
>private var c:Int
>var d:Int
>}

There was a very intentional decision made to *not* do this.  The reason is 
that we don't want to allow a library to accidentally commit to a public API 
contract through an "error of omission".  For example, suppose `d` wasn't 
really intended to be visible outside the module but the author forgot to add 
an `internal` annotation.  This is a problem as soon as the library is 
published.

I think this was the right decision.  It's also worth noting the fact that most 
Swift users have a couple years of experience where omitting the access 
modifier means `internal`.  This means an "error of omission" in this regard is 
more likely for experienced Swift users than it might otherwise be if things 
worked the way you suggest from the beginning.

> 
> Now the fact that I have chosen to make ‘c’ private really stands out much 
> better.  When revisiting the code in 6 months, the struct is much more 
> “glance-able” (as a friend of mine likes to say).
> 
> Note also the nuance that I didn’t say that those vars were marked public (or 
> had the same modifier), I said that they had the SAME VISIBILITY as the 
> enclosing scope (which in this case happens to be public).  This is a concept 
> which is hard to express currently, and IIRC this is what we had to do to 
> make the edge cases of swift 3’s private modifier work properly.  
> 
> Basically, it already works this way for ‘private’, ‘fileprivate’, & 
> ‘internal’, just not for ‘public’ or ‘open’… which can be surprising, 
> especially since you don’t discover these differences until you are working 
> across modules.  We should just extend that mental model up to include public 
> and open.  Migration would just take internal variables of public/open types 
> and mark them explicitly with the word ‘internal'.
> 
> Thanks,
> Jon
> 
> ___
> 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

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Adrian Zubarev via swift-evolution]

Personally I’d prefer if we all together with the core team set down (virtually 
^^) and:

Fully re-evaluated all the access modifier mess and sketched a new future 
oriented model on how this should have been regardless it’s breaking change or 
not.
Communicated the corrected model with the community.
Only after #2 we should made a decision on how to proceed.
The reason I see this that way, because some part of the language seems to be a 
rushed mistake that everyone should now live with, just because we seek for ABI 
stability, we are unable to build a rocket, because our hands are tied.



-- 
Adrian Zubarev
Sent with Airmail

Am 13. Februar 2017 um 15:30:20, David Hart (da...@hartbit.com) schrieb:

Very good graphic. But it reinforces my opinion that it's currently more 
messy/complicated than I should be. It looks like an over-designed or 
designed-by-comitee model. I understand that private is useful, but not useful 
enough to warrant the increased complexity. My 2 cents.

On 13 Feb 2017, at 15:25, Adrian Zubarev via swift-evolution 
 wrote:

I actually made a small visual of how open vs. public should work constantly on 
twitter: https://twitter.com/DevAndArtist/status/829688528216924160




-- 
Adrian Zubarev
Sent with Airmail

Am 13. Februar 2017 um 15:20:10, Matthew Johnson via swift-evolution 
(swift-evolution@swift.org) schrieb:



Sent from my iPad

> On Feb 13, 2017, at 1:35 AM, Rien via swift-evolution 
>  wrote:
>
>
>> On 13 Feb 2017, at 06:16, Derrick Ho via swift-evolution 
>>  wrote:
>>
>> I think I we can live with the original three: public, internal, and private
>>
>> Where public is visible to all,
>> Internal is visible to all within the module, and private is visible only to 
>> the class and the same file.
>>
>> We can still fulfill the same roles that the current five fill.
>>
>> Open can become public again.
>> Public can become final public

This is incorrect. The way `public` behaves today is very different than `final 
public`. Today it only restricts clients of a library from subclassing the 
class. `final public` also prevents the library itself from doing this not only 
in future versions, but also in the current version. This is very useful 
behavior that is not available if we adopt your suggestion.

>> Internal remains the same
>> Fileprivate assimilates into private
>>
>> Make access control simple again!
>
> Agree.
>
> To me this discussion exemplifies the “square peg in a round hole” problem.
> None of these (fileprivate & open) keywords add information to a source code. 
> They do add noise however.
>
> The difference between fileprivate and private is only of importance to a 
> group development effort. And then it is used for internal communication 
> within that group, never to the outside world. In a way “private” tells other 
> group members that they should ask the original developer why he choose 
> private instead of fileprivate. (And more than often be told “just change it”)
> This is something that would be better solved by comments imo.

This is not true at all. I have found the distinction useful both in personal 
projects and in a team environment.

>
> Open vs public is less obvious as there seems to be a use case for this. 
> However in the end it only “forces” an API user to wrap the “public” 
> interface so he can then use it again as “open”.
> Hence it does not solve a design problem, it only leads to a cumbersome 
> interface.

Composition is often a better approach than inheritance. Allowing a library to 
expose classes publicly is very valuable. It allows them the ability to design 
classes that are not intended to be subclasses and have that intent verified by 
the compiler. Supporting subclassing correctly is difficult and not always 
appropriate.

>
>
> Now, if we really want to add information to the source code, then we would 
> do away with the restriction approach entirely and adopt an access list 
> approach. I.e. it would be possible to specify for each interface element 
> which other module/file has access to it.

A long list of access specifications does not lend itself to clarity or 
conciseness. While it is more specific, it is also far more difficult to 
comprehend. Swift strikes a pretty good balance of control, clarity of intent 
and conciseness IMO, but ultimately this is a judgement call.

>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
>>
>
>> On Sun, Feb 12, 2017 at 9:42 PM Xiaodi Wu via swift-evolution 
>>  wrote:
>> On Sun, Feb 12, 2017 at 8:37 PM, Dietmar Planitzer  wrote:
>> I know that private was scoped to files before Swift 3.
>>
>> Fileprivate should obviously be removed because it is, like I said 
>> previously, just a poor man’s package access level. Yes, private was scoped 

Re: [swift-evolution] Simplifying Access Using 'Hidden'

[Adrian Zubarev via swift-evolution]

–1

I won’t even try to be constructive on this one. It simply makes me tired of 
all this access modifier mess. open, closed, public, internal, now hidden, 
fileprivate, directoryprivate, moduleprivate, private, I might even forget some 
of the proposed access modifiers.

Instead of adding new stuff that explodes the complexity we should put our 
energy and fix existing issues, like the inconsistent open for example.



-- 
Adrian Zubarev
Sent with Airmail

Am 13. Februar 2017 um 15:06:45, Jonathan Hull via swift-evolution 
(swift-evolution@swift.org) schrieb:

I wanted to propose a second simplification to the access system which would 
have several benefits:

• It would remove ‘fileprivate’
• It would allow extensions to be in their own files
• It would serve the needs of ‘protected’ without the complications involved in 
that
• It would serve some of the needs of submodules (but also work together with 
them really nicely when we have both)
• It would allow protocols to have something similar to private methods, which 
are not exposed to callers of the protocol, but still required for conformance


My proposal is to add a ‘hidden’ access modifier which would act as a separate 
AXIS as opposed to a new level. Thus, it could be combined with any of the 
other modifiers (e.g. 'public hidden var’). The ‘fileprivate’ level would be 
removed.

Anything which is marked hidden is not visible outside of the file it is 
defined in. That visibility can be explicitly restored on a per file basis (but 
only within the defined access level). Take a look at the following:

//File: MyStruct.swift

struct MyStruct {
var a:Int
hidden var b:Int
}

extension MyStruct {
var biggest:Int {return max(a,b)} //We can still see ‘b’ because it is only 
hidden outside the file
}

Here we see that ‘b’ behaves very similarly to the way fileprivate works now. 
‘b’ is technically still internal, but it is hidden and thus can’t be seen 
outside the file. The difference is that instead of being forced to add all of 
our extensions in the same file, we can organize them however we prefer.

//In another file
import hidden MyStruct //This exposes all ‘hidden’ items from the file MyStruct 
to this file

extension MyStruct {
var c:Int {return a + b} //We can see ‘b’ because of the ‘import hidden’ 
statement
}


Notice how the intent has been shown here. ‘b’ is marked ‘internal’, which 
means we know that no one can see ‘b’ outside of the module. In addition ‘b’ is 
marked ‘hidden’, which means that the author is saying that this should only 
really be accessed from extensions, subclasses, or types which would be called 
friends in other languages. The actual guarantee is still ‘internal’, but a 
caller does have to explicitly request the access by typing ‘import hidden’, 
which will stop accidental/casual misuse. (If/when we get submodules, then we 
can make tighter guarantees)

This also allows a class to “hide the ejection seat levers” from its callers, 
while still allowing access for subclasses and extensions (i.e. it does most of 
what ‘protected’ would do, but with swift’s simpler file-based access model)

The same is true of protocols. There are often methods I have to include on 
protocols which are needed by the default implementations, but NEVER meant to 
be called directly by callers of the protocol. If vars/methods of a protocol 
are marked hidden, then they would be hidden from callers of the protocol 
outside the file. They are still required for conformance, however*.  

protocol MyProtocol {
var a:Int
hidden var b:Int //Conformers still need to provide this, but callers can’t see 
it
}

extension MyProtocol {
func doSomethingBasedOnB() {
//The extension can see b in the same file, but callers in other files won’t 
have access to ‘b’ directly
}
}

I think all of this works really well with Swift’s goal of progressive 
disclosure. Users of protocols/classes/etc… are not exposed to the internals 
necessary for extension (e.g. it won’t come up in autocomplete) until they 
actually need to conform/subclass/extend. Users won’t even need to learn about 
‘hidden' until they are trying to extend a type which uses it (in a way which 
requires access to those internals), or they are writing their own framework. 
It has a simple and consistent meaning based on Swift’s original file-based 
access, but allows power/flexibility (without too much bookkeeping/boilerplate) 
where needed.

Thanks,
Jon


* One detail needed to make things useful for protocols, is that both hidden 
and non-hidden vars/methods on the conforming type should count towards 
conformance of hidden vars/methods on the protocol. Basically, marking 
something as ‘hidden’ on a protocol means it isn’t seen by the caller (only 
conformers/extensions). It makes sense to allow the conformer not to expose 
that either, unless desired. It would technically work fine without this 
allowance, but it ‘feels right’ and people would ask for it quickly...

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Brent Royal-Gordon via swift-evolution]

Sorry, I meant to jump in a lot earlier than this, but lost track of this 
thread on my mental to-do list. I've read most of the thread, but I really 
can't keep all the replies in my head at once, so I apologize if some of this 
is duplicative.

I agree with Jordan Rose that "closed enums" and "closed protocols" are 
separate things and they should be discussed separately, so I'll be doing that 
here. But first, a criticism of both:

> On Feb 8, 2017, at 3:05 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> This proposal introduces the new access modifier `closed` as well as 
> clarifying the meaning of `public` and expanding the use of `open`.

If the `closed` keyword is to stand alone as an access level, I think `closed` 
is a bad choice. `open` is acceptable because it sounds as visible or even 
*more* visible than `public`. (AppKit is "public", but GTK is "open". Which 
exposes more of itself to a programmer?) But `closed` sounds like some form of 
privacy. I think that, unless it's paired with a word like `public`, it will 
not be understood correctly.

Closed enums:

> A recent thread 
> (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031566.html)
>  discussed a similar tradeoff regarding whether public enums should commit to 
> a fixed set of cases by default or not.  The current behavior is that they 
> *do* commit to a fixed set of cases and there is no option (afaik) to modify 
> that behavior.  The Library Evolution document 
> (https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#enums) 
> suggests a desire to change this before locking down ABI such that public 
> enums *do not* make this commitment by default, and are required to opt-in to 
> this behavior using an `@closed` annotation.
> 
> In the previous discussion I stated a strong preference that closed enums 
> *not* be penalized with an additional annotation.  This is because I feel 
> pretty strongly that it is a design smell to: 1) expose cases publicly if 
> consumers of the API are not expected to switch on them and 2) require users 
> to handle unknown future cases if they are likely to switch over the cases in 
> correct use of the API.

The thing is, you do *lots* of things with enums other than exhaustively 
switching on them. One extremely common example is `Error` enums. But even 
leaving that aside, there are lots of cases where you construct an enum and 
hand it off to a library to work or interpret it; adding a case won't break 
these.

Basically, when an enum is an input to a library, adding cases is safe. When 
it's an output from a library, adding cases is potentially unsafe, unless the 
code using the enum is designed to permit additional cases. 

> The conclusion I came to in that thread is that we should adopt the same 
> strategy as we did with classes: there should not be a default.

But classes *do* have a default: closed, i.e., `public`. It is an extremely 
soft default, and we've made it as easy as possible to switch to `open`, but 
`public` is absolutely the default—both because `public` is the keyword people 
will know from other languages, and because `public` is the term used with 
non-class-related symbols.

And remember, it's the default for a good reason: `public`'s semantic is the 
more forgiving one. If you make a class `public` when it should be `open`, 
fixing it is not a breaking change, but the opposite is.

In the case of enums, public-but-nonexhaustive is the more forgiving semantic. 
If you make something public-but-nonexhaustive when it should be 
public-but-exhaustive, fixing it is not a breaking change, but the opposite is.

As I mentioned earlier, I don't think `closed` is a good keyword standing 
alone. And I also think that, given that we have `open`, `closed` also won't 
pair well with `public`—they sound like antonyms when they aren't.

What I instead suggest is that we think of a closed enum as being like a 
fragile (non-resilient) struct. In both cases, you are committing to a 
particular design for the type. So I think we should give them both the same 
keyword—something like:

@fixed struct Person {
var name: String
var birthDate: Date
}
@fixed enum Edge {
case start
case end
}

As I mentioned in another post, inheriting from an enum is not really a 
sensible thing to do. It is perhaps possible that we could eventually introduce 
`open enum`s, which would permit you to add cases in outside extensions. (That 
might be useful for error enums, but I honestly can't think of many other use 
cases.) But enums would need to gain new features—like member overrides 
attached to cases—to make that useful. All in all, I'm not entirely convinced 
about open enums.

Closed protocols:

> There have also been several discussions both on the list and via Twitter 
> regarding whether or not we should allow closed protocols.  In a 

[swift-evolution] Simplifying Access Using 'Hidden'

[Jonathan Hull via swift-evolution]

I wanted to propose a second simplification to the access system which would 
have several benefits:

• It would remove ‘fileprivate’
• It would allow extensions to be in their own files
• It would serve the needs of ‘protected’ without the complications 
involved in that
• It would serve some of the needs of submodules (but also work 
together with them really nicely when we have both)
• It would allow protocols to have something similar to private 
methods, which are not exposed to callers of the protocol, but still required 
for conformance


My proposal is to add a ‘hidden’ access modifier which would act as a separate 
AXIS as opposed to a new level.  Thus, it could be combined with any of the 
other modifiers (e.g. 'public hidden var’).  The ‘fileprivate’ level would be 
removed.

Anything which is marked hidden is not visible outside of the file it is 
defined in.  That visibility can be explicitly restored on a per file basis 
(but only within the defined access level). Take a look at the following:

//File: MyStruct.swift

struct MyStruct {
var a:Int
hidden var b:Int
}

extension MyStruct {
var biggest:Int {return max(a,b)} //We can still see ‘b’ 
because it is only hidden outside the file
}

Here we see that ‘b’ behaves very similarly to the way fileprivate works now.  
‘b’ is technically still internal, but it is hidden and thus can’t be seen 
outside the file.  The difference is that instead of being forced to add all of 
our extensions in the same file, we can organize them however we prefer.

//In another file
import hidden MyStruct //This exposes all ‘hidden’ items from the file 
MyStruct to this file

extension MyStruct {
var c:Int {return a + b} //We can see ‘b’ because of the 
‘import hidden’ statement
}


Notice how the intent has been shown here.  ‘b’ is marked ‘internal’, which 
means we know that no one can see ‘b’ outside of the module.  In addition ‘b’ 
is marked ‘hidden’, which means that the author is saying that this should only 
really be accessed from extensions, subclasses, or types which would be called 
friends in other languages.  The actual guarantee is still ‘internal’, but a 
caller does have to explicitly request the access by typing ‘import hidden’, 
which will stop accidental/casual misuse. (If/when we get submodules, then we 
can make tighter guarantees)

This also allows a class to “hide the ejection seat levers” from its callers, 
while still allowing access for subclasses and extensions (i.e. it does most of 
what ‘protected’ would do, but with swift’s simpler file-based access model)

The same is true of protocols.  There are often methods I have to include on 
protocols which are needed by the default implementations, but NEVER meant to 
be called directly by callers of the protocol.  If vars/methods of a protocol 
are marked hidden, then they would be hidden from callers of the protocol 
outside the file.  They are still required for conformance, however*.  

protocol MyProtocol {
var a:Int
hidden var b:Int  //Conformers still need to provide this, but 
callers can’t see it
}

extension MyProtocol {
func doSomethingBasedOnB() {
//The extension can see b in the same file, but callers 
in other files won’t have access to ‘b’ directly
}
}

I think all of this works really well with Swift’s goal of progressive 
disclosure.  Users of protocols/classes/etc… are not exposed to the internals 
necessary for extension (e.g. it won’t come up in autocomplete) until they 
actually need to conform/subclass/extend.  Users won’t even need to learn about 
‘hidden' until they are trying to extend a type which uses it (in a way which 
requires access to those internals), or they are writing their own framework.  
It has a simple and consistent meaning based on Swift’s original file-based 
access, but allows power/flexibility (without too much bookkeeping/boilerplate) 
where needed.

Thanks,
Jon


* One detail needed to make things useful for protocols, is that both hidden 
and non-hidden vars/methods on the conforming type should count towards 
conformance of hidden vars/methods on the protocol.  Basically, marking 
something as ‘hidden’ on a protocol means it isn’t seen by the caller (only 
conformers/extensions).  It makes sense to allow the conformer not to expose 
that either, unless desired.  It would technically work fine without this 
allowance, but it ‘feels right’ and people would ask for it quickly...

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

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Feb 13, 2017, at 1:35 AM, Rien via swift-evolution 
>  wrote:
> 
> 
>> On 13 Feb 2017, at 06:16, Derrick Ho via swift-evolution 
>>  wrote:
>> 
>> I think I we can live with the original three: public, internal, and private
>> 
>> Where public is visible to all,
>> Internal is visible to all within the module, and private is visible only to 
>> the class and the same file.
>> 
>> We can still fulfill the same roles that the current five fill.
>> 
>> Open can become public again.
>> Public can become final public

This is incorrect.  The way `public` behaves today is very different than 
`final public`.  Today it only restricts clients of a library from subclassing 
the class.  `final public` also prevents the library itself from doing this not 
only in future versions, but also in the current version.  This is very useful 
behavior that is not available if we adopt your suggestion.

>> Internal remains the same
>> Fileprivate assimilates into private
>> 
>> Make access control simple again!
> 
> Agree.
> 
> To me this discussion exemplifies the “square peg in a round hole” problem.
> None of these (fileprivate & open) keywords add information to a source code. 
> They do add noise however.
> 
> The difference between fileprivate and private is only of importance to a 
> group development effort. And then it is used for internal communication 
> within that group, never to the outside world. In a way “private” tells other 
> group members that they should ask the original developer why he choose 
> private instead of fileprivate. (And more than often be told “just change it”)
> This is something that would be better solved by comments imo.

This is not true at all.  I have found the distinction useful both in personal 
projects and in a team environment.

> 
> Open vs public is less obvious as there seems to be a use case for this. 
> However in the end it only “forces” an API user to wrap the “public” 
> interface so he can then use it again as “open”.
> Hence it does not solve a design problem, it only leads to a cumbersome 
> interface.

Composition is often a better approach than inheritance.  Allowing a library to 
expose classes publicly is very valuable.  It allows them the ability to design 
classes that are not intended to be subclasses and have that intent verified by 
the compiler.  Supporting subclassing correctly is difficult and not always 
appropriate.

> 
> 
> Now, if we really want to add information to the source code, then we would 
> do away with the restriction approach entirely and adopt an access list 
> approach. I.e. it would be possible to specify for each interface element 
> which other module/file has access to it.

A long list of access specifications does not lend itself to clarity or 
conciseness.  While it is more specific, it is also far more difficult to 
comprehend.  Swift strikes a pretty good balance of control, clarity of intent 
and conciseness  IMO, but ultimately this is a judgement call.

> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
>> 
> 
>> On Sun, Feb 12, 2017 at 9:42 PM Xiaodi Wu via swift-evolution 
>>  wrote:
>> On Sun, Feb 12, 2017 at 8:37 PM, Dietmar Planitzer  wrote:
>> I know that private was scoped to files before Swift 3.
>> 
>> Fileprivate should obviously be removed because it is, like I said 
>> previously, just a poor man’s package access level. Yes, private was scoped 
>> to a file before Swift 3, but at least there wasn’t two kinds of private for 
>> a single file. Also scoping private to a file makes sense in Swift because 
>> it plays well with the ability to organize the implementation of a type 
>> inside of a file into the base type and a number of extensions. I now have 
>> to use fileprivate in Swift 3 to pull this off while there isn’t a 
>> requirement for a separate private access level. The fileprivate / private 
>> distinction also needlessly gets in the way when you want to refactor an 
>> existing type implementation into base type + extensions, all living in the 
>> same file.
>> 
>> Anyway, I don’t see a good reason why we should end up with this, once 
>> sub-modules exist:
>> 
>> open, public, module, fileprivate, private
>> 
>> when we can live with this:
>> 
>> open, public, module, private
>> 
>> and we’re not losing anything that would be significant compared to the 
>> alternative scenario.
>> 
>> Well, there's also internal: open, public, internal, (submodule, however it 
>> is named), private.
>> 
>> The question being discussed here is whether private should have the old or 
>> new meaning. I tend to agree with others that the new `private` doesn't add 
>> much. Modules are a different conversation.
>> 
>> Regards,
>> 
>> Dietmar Planitzer
>> 
>>> On Feb 12, 2017, at 18:16, 

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Matthew Johnson via swift-evolution]

> On Feb 13, 2017, at 8:24 AM, Brent Royal-Gordon  
> wrote:
> 
> Sorry, I meant to jump in a lot earlier than this, but lost track of this 
> thread on my mental to-do list. I've read most of the thread, but I really 
> can't keep all the replies in my head at once, so I apologize if some of this 
> is duplicative.

Hi Brent, no problem!  Thanks for taking time to read it and offer feedback.

> 
> I agree with Jordan Rose that "closed enums" and "closed protocols" are 
> separate things and they should be discussed separately, so I'll be doing 
> that here. But first, a criticism of both:

I agree that they are separate things.  But there is also important semantic 
overlap.  One of the major motivations behind my proposal is that I think we’re 
ignoring this semantic overlap and therefore being sloppy with our terminology. 
 I think it would be wise to consider carefully whether it is a good idea to 
continue ignoring the overlap.  I think one can make an argument that it 
ignoring it is a pragmatic choice, but one can also make an argument that it is 
hand-wavy.  

If you look closely, when most people say “closed enum” they mean a fixed, 
complete set of cases that are all public.  But when people say “closed 
protocol” they don’t actually mean a fixed, complete set of conformances that 
are all public.  They simply mean clients cannot add conformances.  This is the 
semantic contract of resilient enums, not closed enums.

> 
>> On Feb 8, 2017, at 3:05 PM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> This proposal introduces the new access modifier `closed` as well as 
>> clarifying the meaning of `public` and expanding the use of `open`.
> 
> If the `closed` keyword is to stand alone as an access level, I think 
> `closed` is a bad choice. `open` is acceptable because it sounds as visible 
> or even *more* visible than `public`. (AppKit is "public", but GTK is "open". 
> Which exposes more of itself to a programmer?) But `closed` sounds like some 
> form of privacy. I think that, unless it's paired with a word like `public`, 
> it will not be understood correctly.

This certainly is a fair criticism.  `closed` is the term that has been heavily 
used by the community and is an inverse of `open`, which makes sense because it 
is in many respects a semantic inverse.  That said, I would embrace a healthy 
round of bike shedding to try and find a better keyword.

> 
> Closed enums:
> 
>> A recent thread 
>> (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031566.html)
>>  discussed a similar tradeoff regarding whether public enums should commit 
>> to a fixed set of cases by default or not.  The current behavior is that 
>> they *do* commit to a fixed set of cases and there is no option (afaik) to 
>> modify that behavior.  The Library Evolution document 
>> (https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#enums) 
>> suggests a desire to change this before locking down ABI such that public 
>> enums *do not* make this commitment by default, and are required to opt-in 
>> to this behavior using an `@closed` annotation.
>> 
>> In the previous discussion I stated a strong preference that closed enums 
>> *not* be penalized with an additional annotation.  This is because I feel 
>> pretty strongly that it is a design smell to: 1) expose cases publicly if 
>> consumers of the API are not expected to switch on them and 2) require users 
>> to handle unknown future cases if they are likely to switch over the cases 
>> in correct use of the API.
> 
> The thing is, you do *lots* of things with enums other than exhaustively 
> switching on them. One extremely common example is `Error` enums. But even 
> leaving that aside, there are lots of cases where you construct an enum and 
> hand it off to a library to work or interpret it; adding a case won't break 
> these.
> 
> Basically, when an enum is an input to a library, adding cases is safe. When 
> it's an output from a library, adding cases is potentially unsafe, unless the 
> code using the enum is designed to permit additional cases. 

Yes, I agree with this.  I was overreaching a bit in that paragraph.  My point 
is that you can achieve the same client syntax for library inputs using designs 
that don’t expose cases publicly (i.e. discourage users from writing a switch). 
 Maybe, at least in some cases, that is what a library should do.  Saying it 
*is* a design smell was an exaggeration, but saying it is a contract worthy of 
close consideration is accurate.

> 
>> The conclusion I came to in that thread is that we should adopt the same 
>> strategy as we did with classes: there should not be a default.
> 
> But classes *do* have a default: closed, i.e., `public`. It is an extremely 
> soft default, and we've made it as easy as possible to switch to `open`, but 
> `public` is absolutely the default—both because `public` is the keyword 
> people will know 

Re: [swift-evolution] Simplifying Access Using 'Hidden'

[Joanna Carter via swift-evolution]

Le 13/02/2017 à 15:15, Adrian Zubarev via swift-evolution a écrit : 

>  –1 
> 
> I won’t even try to be constructive on this one. It simply makes me 
> tired of all this access modifier mess. |open|, |closed|, |public|, 
> |internal|, now |hidden|, |fileprivate|, |directoryprivate|, 
> |moduleprivate|, |private|, I might even forget some of the proposed 
> access modifiers. 
> 
> Instead of adding new stuff that explodes the complexity we should put 
> our energy and fix existing issues, like the inconsistent |open| for 
> example. 

I would also say that access modifiers do seem to be be somewhat messy. 

I have never liked the idea of fileprivate ; this is the equivalent of Delphi's 
private scope, to which they then added strict private for class only scope. 
That was a similar mess. 

I am still not sure why we can't have the good old-fashioned visibilities of 
private, protected and public for classes. They have worked well for years and 
I feel we are changing things for change's sake. 

For all types other than classes, where inheritance is a feature, we have 
private, internal and public. 

For classes, we should definitely add protected ; I find internal just too 
exposing for stuff to be used exclusively by derived classes. 

But, I believe one of the motives behind fileprivate was to satisfy the need 
for extensions to a type to access private members. 

Just to put in my 2¢ worth, the only extra scope I would suggest could be named 
"extensible" and would allow anything so marked to be visible only as far as 
extensions ; the difference being that such extensions could then be placed in 
separate files. 

So, private, protected (class only), internal, public and extensible. 

Or is that too revolutionary ? 

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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Adrian Zubarev via swift-evolution]

Is that assumption correct?

// Module A
public protocol SQLiteValue {
init(statement: SQLiteStatement, columnAt index: Int) throws
func bind(to statement: SQLiteStatement, at index: Int) throws
}

// Module B
protocol SQLiteLoggable : SQLiteValue {
var logDescription: String { get }
}
I could not follow your example there. If SQLiteLoggable is from module B than 
this should be an error in my opinion. Otherwise open would have less meaning 
on protocols, because you always could create an empty protocol that has a 
super public protocol which you’re not allowed to conform to in module B. This 
would be a silly workaround to being able to conform to it SQLiteValue 
indirectly without any further requirement like in SQLiteValueConvertible.

That said, it makes no sense to me to allow that, because it’s simply a 
workaround to conform to a protocol which public-but-not-open tries to prevent.

// Module X
public protocol A {}

open protocol AA : A { func foo() } // Fine

// Module Y
struct B : A {} // Error
struct B : AA { func foo() { .. } } // Okay

protocol C : A {} // Error because `struct B : C` would equal `struct B : A`
protocol CC : AA {} // Should work even empty, because we have more requirement 
from `AA`
public should have a consistent meaning across all types from module A in 
module B, which is ‘not allowed to sub-type from’ and in case of protocols 
additionally ‘not allowed to conform to’.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Matthew Johnson via swift-evolution]

> On Feb 13, 2017, at 10:19 AM, Karl Wagner  wrote:
> 
>> 
>>> 
>>> As I mentioned earlier, I don't think `closed` is a good keyword standing 
>>> alone. And I also think that, given that we have `open`, `closed` also 
>>> won't pair well with `public`—they sound like antonyms when they aren’t.
>> 
>> The semantics I am proposing do have an inverse relationship.  That said, it 
>> may not be an intuitive or immediately obvious inverse.  I am certainly not 
>> wedded to the idea of using `closed` as the keyword.
>> 
>>> 
>>> What I instead suggest is that we think of a closed enum as being like a 
>>> fragile (non-resilient) struct. In both cases, you are committing to a 
>>> particular design for the type. So I think we should give them both the 
>>> same keyword—something like:
>>> 
>>> @fixed struct Person {
>>> var name: String
>>> var birthDate: Date
>>> }
>>> @fixed enum Edge {
>>> case start
>>> case end
>>> }
>>> 
>> 
> 
> What about “final”?
> 

Final has a very different meaning: this type has no subtypes.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Tino Heth via swift-evolution]

> Personally I’d prefer if we all together with the core team set down 
> (virtually ^^) and:
> 
> Fully re-evaluated all the access modifier mess and sketched a new future 
> oriented model on how this should have been regardless it’s breaking change 
> or not.
+1
imho the current situation is an anti-sweetspot:
It lacks the elegant simplicity of the original model, but still isn't powerful 
enough for many things.
> Communicated the corrected model with the community.
> Only after #2 we should made a decision on how to proceed.
> The reason I see this that way, because some part of the language seems to be 
> a rushed mistake that everyone should now live with, just because we seek for 
> ABI stability, we are unable to build a rocket, because our hands are tied.
> 
Yes — and I would really appreciate if not only this topic is reviewed with the 
added experience of real-life usage of Swift.
Maybe there are some things that are to basic even for the list of commonly 
rejected proposals*, because they are either unthinkable or seem to large for 
the evolution process (there is a strong preference for proposals that are only 
small refinements for the language, so it is easy to lose sight of the big 
picture).
I wouldn't expect actual changes triggered by such a discussion, but I'm also 
very interested in getting to know the motives of fundamental decisions that 
happened before Swift went Open source.

- Tino

* Things like:
- Are Repeat-While and While-loops really necessary? I bet many never use them
- Why are optionals modelled as enums? Union types have some nice 
characteristics for this use case
- What's the point of enums with associated values anyways? Aren't case classes 
nicer?
...___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Karl Wagner via swift-evolution]

> 
>> 
>> As I mentioned earlier, I don't think `closed` is a good keyword standing 
>> alone. And I also think that, given that we have `open`, `closed` also won't 
>> pair well with `public`—they sound like antonyms when they aren’t.
> 
> The semantics I am proposing do have an inverse relationship.  That said, it 
> may not be an intuitive or immediately obvious inverse.  I am certainly not 
> wedded to the idea of using `closed` as the keyword.
> 
>> 
>> What I instead suggest is that we think of a closed enum as being like a 
>> fragile (non-resilient) struct. In both cases, you are committing to a 
>> particular design for the type. So I think we should give them both the same 
>> keyword—something like:
>> 
>>  @fixed struct Person {
>>  var name: String
>>  var birthDate: Date
>>  }
>>  @fixed enum Edge {
>>  case start
>>  case end
>>  }
>> 
> 

What about “final”?

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

Re: [swift-evolution] Simplifying Access Using 'Hidden'

[Adrian Zubarev via swift-evolution]

People talk always like “I never liked fileprivate” and I feel like some of you 
forgot that fileprivate is not new to Swift. It’s the repainted private from 
days before Swift 3. I cannot recall anyone complaining about it that much. 
There were some people that forced the addition of a stricter private access 
modifier for Swift 3. Now that we have both, there are a lot of complains about 
fileprivate.



-- 
Adrian Zubarev
Sent with Airmail

Am 13. Februar 2017 um 17:10:45, Joanna Carter via swift-evolution 
(swift-evolution@swift.org) schrieb:

Le 13/02/2017 à 15:15, Adrian Zubarev via swift-evolution a écrit :  

> –1  
>  
> I won’t even try to be constructive on this one. It simply makes me  
> tired of all this access modifier mess. |open|, |closed|, |public|,  
> |internal|, now |hidden|, |fileprivate|, |directoryprivate|,  
> |moduleprivate|, |private|, I might even forget some of the proposed  
> access modifiers.  
>  
> Instead of adding new stuff that explodes the complexity we should put  
> our energy and fix existing issues, like the inconsistent |open| for  
> example.  

I would also say that access modifiers do seem to be be somewhat messy.  

I have never liked the idea of fileprivate ; this is the equivalent of Delphi's 
private scope, to which they then added strict private for class only scope. 
That was a similar mess.  

I am still not sure why we can't have the good old-fashioned visibilities of 
private, protected and public for classes. They have worked well for years and 
I feel we are changing things for change's sake.  

For all types other than classes, where inheritance is a feature, we have 
private, internal and public.  

For classes, we should definitely add protected ; I find internal just too 
exposing for stuff to be used exclusively by derived classes.  

But, I believe one of the motives behind fileprivate was to satisfy the need 
for extensions to a type to access private members.  

Just to put in my 2¢ worth, the only extra scope I would suggest could be named 
"extensible" and would allow anything so marked to be visible only as far as 
extensions ; the difference being that such extensions could then be placed in 
separate files.  

So, private, protected (class only), internal, public and extensible.  

Or is that too revolutionary ?  

Joanna  
___
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

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

[Alejandro Martinez via swift-evolution]

On class vs. AnyObject, probablt a dumb question but maybe worth
clarifying, we don't pretend to change it in a class declaration
right?

like

AnyObject A {
 var 
}

apart from that looking forward for this!


On Sun, Feb 12, 2017 at 8:32 PM, David Hart via swift-evolution
 wrote:
> Hi Matthew,
>
> Your arguments made sense to me. I modified the proposal to choose strategy
> number 3: deprecating and removing class over several versions to favour
> AnyObject. Mind having another proof read?
>
> https://github.com/hartbit/swift-evolution/blob/subclass-existentials/proposals/-subclass-existentials.md
>
> Anybody has counter arguments?
>
> Class and Subtype existentials
>
> Proposal: SE-
> Authors: David Hart, Austin Zheng
> Review Manager: TBD
> Status: TBD
>
> Introduction
>
> This proposal brings more expressive power to the type system by allowing
> Swift to represent existentials of classes and subtypes which conform to
> protocols.
>
> Motivation
>
> Currently, the only existentials which can be represented in Swift are
> conformances to a set of protocols, using the  composition syntax:
>
> Protocol1 & Protocol2
>
> On the other hand, Objective-C is capable of expressing existentials of
> classes and subclasses conforming to protocols with the following syntax:
>
> id
> Base*
>
> We propose to provide similar expressive power to Swift, which will also
> improve the bridging of those types from Objective-C.
>
> Proposed solution
>
> The proposal keeps the existing & syntax but allows the first element, and
> only the first, to be either the AnyObjectkeyword or of class type. The
> equivalent to the above Objective-C types would look like this:
>
> AnyObject & Protocol1 & Protocol2
> Base & Protocol
>
> As in Objective-C, the first line is an existential of classes which conform
> to Protocol1 and Protocol2, and the second line is an existential of
> subtypes of Base which conform to Protocol.
>
> Here are the new proposed rules for what is valid in a existential
> conjunction syntax:
>
> 1. The first element in the protocol composition syntax can be the AnyObject
> keyword to enforce a class constraint:
>
> protocol P {}
> struct S : P {}
> class C : P {}
> let t: P & AnyObject // Compiler error: AnyObject requirement must be in
> first position
> let u: AnyObject & P = S() // Compiler error: S is not of class type
> let v: AnyObject & P = C() // Compiles successfully
>
> 2. The first element in the protocol composition syntax can be a class type
> to enforce the existential to be a subtype of the class:
>
> protocol P {}
> struct S {}
> class C {}
> class D : P {}
> class E : C, P {}
> let t: P & C // Compiler error: subclass constraint must be in first
> position
> let u: S & P // Compiler error: S is not of class type
> let v: C & P = D() // Compiler error: D is not a subtype of C
> let w: C & P = E() // Compiles successfully
>
> 3. When a protocol composition type contains a typealias, the validity of
> the type is determined using the following steps:
>
> Expand the typealias
> Normalize the type by removing duplicate constraints and replacing less
> specific constraints by more specific constraints (a class constraint is
> less specific than a class type constraint, which is less specific than a
> constraint of a subclass of that class).
> Check that the type does not contain two class-type constraints
>
> class C {}
> class D : C {}
> class E {}
> protocol P1 {}
> protocol P2 {}
> typealias TA1 = AnyObject & P1
> typealias TA2 = AnyObject & P2
> typealias TA3 = C & P2
> typealias TA4 = D & P2
> typealias TA5 = E & P2
>
> typealias TA5 = TA1 & TA2
> // Expansion: typealias TA5 = AnyObject & P1 & AnyObject & P2
> // Normalization: typealias TA5 = AnyObject & P1 & P2
> // TA5 is valid
>
> typealias TA6 = TA1 & TA3
> // Expansion: typealias TA6 = AnyObject & P1 & C & P2
> // Normalization (AnyObject < C): typealias TA6 = C & P1 & P2
> // TA6 is valid
>
> typealias TA7 = TA3 & TA4
> // Expansion: typealias TA7 = C & P2 & D & P2
> // Normalization (C < D): typealias TA7 = D & P2
> // TA7 is valid
>
> typealias TA8 = TA4 & TA5
> // Expansion: typealias TA8 = D & P2 & E & P2
> // Normalization: typealias TA8 = D & E & P2
> // TA8 is invalid because the D and E constraints are incompatible
>
> class and AnyObject
>
> This proposal merges the concepts of class and AnyObject, which now have the
> same meaning: they represent an existential for classes. To get rid of the
> duplication, we suggest only keeping AnyObject around. To reduce
> source-breakage to a minimum, class could be redefined as typealias class =
> AnyObject and give a deprecation warning on class for the first version of
> Swift this proposal is implemented in. Later, class could be removed in a
> subsequent version of Swift.
>
> Source compatibility
>
> This change will not break Swift 3 compability mode because Objective-C
> types will continue to be imported as before. But in 

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Adrian Zubarev via swift-evolution]

Okay thanks, that makes now sense to me. So even if we refine public protocols 
from module A with a custom protocol in module B, there is no way we can 
conform any other type from module B to it, but we could conform existing types 
of module A to our refined protocols.

That’s fine by me, because the consistent restriction of public would remain 
the same. :)



-- 
Adrian Zubarev
Sent with Airmail

Am 13. Februar 2017 um 17:27:36, Matthew Johnson (matt...@anandabits.com) 
schrieb:


On Feb 13, 2017, at 10:14 AM, Adrian Zubarev via swift-evolution 
 wrote:

Is that assumption correct?

// Module A
public protocol SQLiteValue {
init(statement: SQLiteStatement, columnAt index: Int) throws
func bind(to statement: SQLiteStatement, at index: Int) throws
}

// Module B
protocol SQLiteLoggable : SQLiteValue {
var logDescription: String { get }
}
I could not follow your example there. If SQLiteLoggable is from module B than 
this should be an error in my opinion.

Yes, Brent was using `public protocol` with the same semantics that `public 
class` has today (i.e. not open) so this would be an error.

Otherwise open would have less meaning on protocols, because you always could 
create an empty protocol that has a super public protocol which you’re not 
allowed to conform to in module B. This would be a silly workaround to being 
able to conform to it SQLiteValue indirectly without any further requirement 
like in SQLiteValueConvertible.

That said, it makes no sense to me to allow that, because it’s simply a 
workaround to conform to a protocol which public-but-not-open tries to prevent.

// Module X
public protocol A {}

open protocol AA : A { func foo() } // Fine

// Module Y
struct B : A {} // Error
struct B : AA { func foo() { .. } } // Okay
No, `struct B : AA` is an error because in order to conform to `AA`, `B` must 
also conform to `A`, which it cannot because `A` is closed.



protocol C : A {} // Error because `struct B : C` would equal `struct B : A`
No, this is allowed.  However the only types that can conform to `C` are types 
declared in module X that *already* conform to `A`.  They may be extended to 
retroactively conform to `C`.

protocol CC : AA {} // Should work even empty, because we have more requirement 
from `AA`
public should have a consistent meaning across all types from module A in 
module B, which is ‘not allowed to sub-type from’ and in case of protocols 
additionally ‘not allowed to conform to’.

___
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

Re: [swift-evolution] Simplifying Access Using 'Hidden'

[Karl Wagner via swift-evolution]

> On 13 Feb 2017, at 17:21, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> People talk always like “I never liked fileprivate” and I feel like some of 
> you forgot that fileprivate is not new to Swift. It’s the repainted private 
> from days before Swift 3. I cannot recall anyone complaining about it that 
> much. There were some people that forced the addition of a stricter private 
> access modifier for Swift 3. Now that we have both, there are a lot of 
> complains about fileprivate.
> 
> 
It _is_ kind of ugly. I would support rearranging our access lives like this, 
with a parameterised “private”:

open
public
private(module) // today’s “internal”
private(file)   // today’s “fileprivate”
private // today’s “private”

It also opens the door to more nuanced access levels, such as private(type) to 
allow access to the hidden member in cross-file extensions but not generally 
throughout the module.

For properties, it would mean 

public internal(set) var something: Bool

would become 

public private(module, set) var something: Bool

at which point it might be nicer to flip the arguments and call it “setter”:

public private(setter, module) var something: Bool

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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Matthew Johnson via swift-evolution]

> On Feb 13, 2017, at 10:14 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Is that assumption correct?
> 
> // Module A
> public protocol SQLiteValue {
> init(statement: SQLiteStatement, columnAt index: Int) throws
> func bind(to statement: SQLiteStatement, at index: Int) throws
> }
> 
> // Module B
> protocol SQLiteLoggable : SQLiteValue {
> var logDescription: String { get }
> }
> I could not follow your example there. If SQLiteLoggable is from module B 
> than this should be an error in my opinion.
> 
Yes, Brent was using `public protocol` with the same semantics that `public 
class` has today (i.e. not open) so this would be an error.

> Otherwise open would have less meaning on protocols, because you always could 
> create an empty protocol that has a super public protocol which you’re not 
> allowed to conform to in module B. This would be a silly workaround to being 
> able to conform to it SQLiteValue indirectly without any further requirement 
> like in SQLiteValueConvertible.
> 
> That said, it makes no sense to me to allow that, because it’s simply a 
> workaround to conform to a protocol which public-but-not-open tries to 
> prevent.
> 
> // Module X
> public protocol A {}
> 
> open protocol AA : A { func foo() } // Fine
> 
> // Module Y
> struct B : A {} // Error
> struct B : AA { func foo() { .. } } // Okay
No, `struct B : AA` is an error because in order to conform to `AA`, `B` must 
also conform to `A`, which it cannot because `A` is closed.


> 
> protocol C : A {} // Error because `struct B : C` would equal `struct B : A`
No, this is allowed.  However the only types that can conform to `C` are types 
declared in module X that *already* conform to `A`.  They may be extended to 
retroactively conform to `C`.

> protocol CC : AA {} // Should work even empty, because we have more 
> requirement from `AA`
> public should have a consistent meaning across all types from module A in 
> module B, which is ‘not allowed to sub-type from’ and in case of protocols 
> additionally ‘not allowed to conform to’.
> 
> ___
> 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

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

[Adrian Zubarev via swift-evolution]

No, you’re totally right there. The mentioned class keyword is the protocol 
constraint-keyword such as protocol X : >> class << { … }. Instead we would 
like to generalize AnyObject



-- 
Adrian Zubarev
Sent with Airmail

Am 13. Februar 2017 um 17:34:18, Alejandro Martinez via swift-evolution 
(swift-evolution@swift.org) schrieb:

On class vs. AnyObject, probablt a dumb question but maybe worth
clarifying, we don't pretend to change it in a class declaration
right?

like

AnyObject A {
var 
}

apart from that looking forward for this!


On Sun, Feb 12, 2017 at 8:32 PM, David Hart via swift-evolution
 wrote:
> Hi Matthew,
>
> Your arguments made sense to me. I modified the proposal to choose strategy
> number 3: deprecating and removing class over several versions to favour
> AnyObject. Mind having another proof read?
>
> https://github.com/hartbit/swift-evolution/blob/subclass-existentials/proposals/-subclass-existentials.md
>
> Anybody has counter arguments?
>
> Class and Subtype existentials
>
> Proposal: SE-
> Authors: David Hart, Austin Zheng
> Review Manager: TBD
> Status: TBD
>
> Introduction
>
> This proposal brings more expressive power to the type system by allowing
> Swift to represent existentials of classes and subtypes which conform to
> protocols.
>
> Motivation
>
> Currently, the only existentials which can be represented in Swift are
> conformances to a set of protocols, using the  composition syntax:
>
> Protocol1 & Protocol2
>
> On the other hand, Objective-C is capable of expressing existentials of
> classes and subclasses conforming to protocols with the following syntax:
>
> id
> Base*
>
> We propose to provide similar expressive power to Swift, which will also
> improve the bridging of those types from Objective-C.
>
> Proposed solution
>
> The proposal keeps the existing & syntax but allows the first element, and
> only the first, to be either the AnyObjectkeyword or of class type. The
> equivalent to the above Objective-C types would look like this:
>
> AnyObject & Protocol1 & Protocol2
> Base & Protocol
>
> As in Objective-C, the first line is an existential of classes which conform
> to Protocol1 and Protocol2, and the second line is an existential of
> subtypes of Base which conform to Protocol.
>
> Here are the new proposed rules for what is valid in a existential
> conjunction syntax:
>
> 1. The first element in the protocol composition syntax can be the AnyObject
> keyword to enforce a class constraint:
>
> protocol P {}
> struct S : P {}
> class C : P {}
> let t: P & AnyObject // Compiler error: AnyObject requirement must be in
> first position
> let u: AnyObject & P = S() // Compiler error: S is not of class type
> let v: AnyObject & P = C() // Compiles successfully
>
> 2. The first element in the protocol composition syntax can be a class type
> to enforce the existential to be a subtype of the class:
>
> protocol P {}
> struct S {}
> class C {}
> class D : P {}
> class E : C, P {}
> let t: P & C // Compiler error: subclass constraint must be in first
> position
> let u: S & P // Compiler error: S is not of class type
> let v: C & P = D() // Compiler error: D is not a subtype of C
> let w: C & P = E() // Compiles successfully
>
> 3. When a protocol composition type contains a typealias, the validity of
> the type is determined using the following steps:
>
> Expand the typealias
> Normalize the type by removing duplicate constraints and replacing less
> specific constraints by more specific constraints (a class constraint is
> less specific than a class type constraint, which is less specific than a
> constraint of a subclass of that class).
> Check that the type does not contain two class-type constraints
>
> class C {}
> class D : C {}
> class E {}
> protocol P1 {}
> protocol P2 {}
> typealias TA1 = AnyObject & P1
> typealias TA2 = AnyObject & P2
> typealias TA3 = C & P2
> typealias TA4 = D & P2
> typealias TA5 = E & P2
>
> typealias TA5 = TA1 & TA2
> // Expansion: typealias TA5 = AnyObject & P1 & AnyObject & P2
> // Normalization: typealias TA5 = AnyObject & P1 & P2
> // TA5 is valid
>
> typealias TA6 = TA1 & TA3
> // Expansion: typealias TA6 = AnyObject & P1 & C & P2
> // Normalization (AnyObject < C): typealias TA6 = C & P1 & P2
> // TA6 is valid
>
> typealias TA7 = TA3 & TA4
> // Expansion: typealias TA7 = C & P2 & D & P2
> // Normalization (C < D): typealias TA7 = D & P2
> // TA7 is valid
>
> typealias TA8 = TA4 & TA5
> // Expansion: typealias TA8 = D & P2 & E & P2
> // Normalization: typealias TA8 = D & E & P2
> // TA8 is invalid because the D and E constraints are incompatible
>
> class and AnyObject
>
> This proposal merges the concepts of class and AnyObject, which now have the
> same meaning: they represent an existential for classes. To get rid of the
> duplication, we suggest only keeping AnyObject around. To reduce
> source-breakage to a minimum, class could be redefined as typealias class =
> 

Re: [swift-evolution] Simplifying Access Using 'Hidden'

[Adrian Zubarev via swift-evolution]

I’ve never said, I liked the keyword by its name, however I do like its 
behavior which opens up flexible ways of creating some code dependency across 
the file. What I really meant is, that I feel like some people talk about 
fileprivate behavior as if it was new, which it is not.

I’m feeling with you about private(file), but I’m not sure about 
private(module), because internal is shorter and seems fine to me. ;)



-- 
Adrian Zubarev
Sent with Airmail

Am 13. Februar 2017 um 17:35:42, Karl Wagner (razie...@gmail.com) schrieb:


On 13 Feb 2017, at 17:21, Adrian Zubarev via swift-evolution 
 wrote:

People talk always like “I never liked fileprivate” and I feel like some of you 
forgot that fileprivate is not new to Swift. It’s the repainted private from 
days before Swift 3. I cannot recall anyone complaining about it that much. 
There were some people that forced the addition of a stricter private access 
modifier for Swift 3. Now that we have both, there are a lot of complains about 
fileprivate.


It _is_ kind of ugly. I would support rearranging our access lives like this, 
with a parameterised “private”:

open
public
private(module) // today’s “internal”
private(file)   // today’s “fileprivate”
private         // today’s “private”

It also opens the door to more nuanced access levels, such as private(type) to 
allow access to the hidden member in cross-file extensions but not generally 
throughout the module.

For properties, it would mean 

public internal(set) var something: Bool

would become 

public private(module, set) var something: Bool

at which point it might be nicer to flip the arguments and call it “setter”:

public private(setter, module) var something: Bool

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

Re: [swift-evolution] Simplifying Default Access Modifiers

[Rien via swift-evolution]

+1

I think this is actually what most people would intuitively expect anyway.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 13 Feb 2017, at 10:02, Jonathan Hull via swift-evolution 
>  wrote:
> 
> I would like to propose a change to the default access modifier within an 
> enclosing scope.  The default for top level definitions would stay internal, 
> but anything within a scope would by default have the same visibility as it’s 
> enclosing scope.
> 
> The main reason for this is readability/maintainability, and having the 
> intention clearly stand out.  It would also reduce a great amount of 
> boilerplate.  It also matches the mental model of how scopes normally work 
> regarding inheritance of visibility/properties (which means less to teach 
> newbies).
> 
> Right now if I want to make a type and all of it’s vars/methods public, I 
> have to mark each individual var/method public, which leads to a lot of 
> boilerplate/noise and makes everything harder to read:
> 
>   public struct MyStruct {
>   public var a:Int
>   public var b:Int
>   private var c:Int
>   public var d:Int
>   }
> 
> Notice that the private var doesn’t really stand out as such very well.  
> Also, it is exceedingly rare (at least in my own coding style) that I 
> actually want an internal variable unless the type itself is internal, and in 
> those cases, I would like that choice to stand out as deliberate the same way 
> I want ‘private' to stand out.  As it stands, I wait until I think I am done 
> modifying a type to mark it public because of the extra noise generated.  I 
> also make a point to write ‘internal' for things that I explicitly want to 
> restrict to internal.
> 
> Consider the alternative:
> 
>   public struct MyStruct {
>   var a:Int
>   var b:Int
>   private var c:Int
>   var d:Int
>   }
> 
> Now the fact that I have chosen to make ‘c’ private really stands out much 
> better.  When revisiting the code in 6 months, the struct is much more 
> “glance-able” (as a friend of mine likes to say).
> 
> Note also the nuance that I didn’t say that those vars were marked public (or 
> had the same modifier), I said that they had the SAME VISIBILITY as the 
> enclosing scope (which in this case happens to be public).  This is a concept 
> which is hard to express currently, and IIRC this is what we had to do to 
> make the edge cases of swift 3’s private modifier work properly.  
> 
> Basically, it already works this way for ‘private’, ‘fileprivate’, & 
> ‘internal’, just not for ‘public’ or ‘open’… which can be surprising, 
> especially since you don’t discover these differences until you are working 
> across modules.  We should just extend that mental model up to include public 
> and open.  Migration would just take internal variables of public/open types 
> and mark them explicitly with the word ‘internal'.
> 
> Thanks,
> Jon
> 
> ___
> 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

[swift-evolution] Simplifying Default Access Modifiers

[Jonathan Hull via swift-evolution]

I would like to propose a change to the default access modifier within an 
enclosing scope.  The default for top level definitions would stay internal, 
but anything within a scope would by default have the same visibility as it’s 
enclosing scope.

The main reason for this is readability/maintainability, and having the 
intention clearly stand out.  It would also reduce a great amount of 
boilerplate.  It also matches the mental model of how scopes normally work 
regarding inheritance of visibility/properties (which means less to teach 
newbies).

Right now if I want to make a type and all of it’s vars/methods public, I have 
to mark each individual var/method public, which leads to a lot of 
boilerplate/noise and makes everything harder to read:

public struct MyStruct {
public var a:Int
public var b:Int
private var c:Int
public var d:Int
}

Notice that the private var doesn’t really stand out as such very well.  Also, 
it is exceedingly rare (at least in my own coding style) that I actually want 
an internal variable unless the type itself is internal, and in those cases, I 
would like that choice to stand out as deliberate the same way I want ‘private' 
to stand out.  As it stands, I wait until I think I am done modifying a type to 
mark it public because of the extra noise generated.  I also make a point to 
write ‘internal' for things that I explicitly want to restrict to internal.

Consider the alternative:

public struct MyStruct {
var a:Int
var b:Int
private var c:Int
var d:Int
}

Now the fact that I have chosen to make ‘c’ private really stands out much 
better.  When revisiting the code in 6 months, the struct is much more 
“glance-able” (as a friend of mine likes to say).

Note also the nuance that I didn’t say that those vars were marked public (or 
had the same modifier), I said that they had the SAME VISIBILITY as the 
enclosing scope (which in this case happens to be public).  This is a concept 
which is hard to express currently, and IIRC this is what we had to do to make 
the edge cases of swift 3’s private modifier work properly.  

Basically, it already works this way for ‘private’, ‘fileprivate’, & 
‘internal’, just not for ‘public’ or ‘open’… which can be surprising, 
especially since you don’t discover these differences until you are working 
across modules.  We should just extend that mental model up to include public 
and open.  Migration would just take internal variables of public/open types 
and mark them explicitly with the word ‘internal'.

Thanks,
Jon

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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[James Froggatt via swift-evolution]

Having loosely followed this discussion, the way I'm thinking of ‘closed’ is as 
a modifier which would let you switch over something from outside the module in 
which it is declared.

From outside the declaring module:
• A closed enum's cases can be exhaustively switched.
• A closed protocol's conforming types can be exhaustively switched.
• A closed class's subclasses can be exhaustively switched.

If this is correct, I can't help but think ‘closed’ is describing something 
subtly different in each case - picking and choosing the ‘important’ 
relationship for each type, while protocols already have a subtyping 
relationship, and it sounds like there's possibility for enum subtyping in the 
future.

I'd rather keep ‘open’ (and a potential future ‘closed’) purely describing the 
subtyping relationship, and have some other means of labelling conformance and 
cases as switchable.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Erica Sadun via swift-evolution]

> On Feb 12, 2017, at 9:19 AM, David Hart via swift-evolution 
>  wrote:
> 
> I was reading this nice listing of Swift keywords 
> (https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh
>  
> )
>  and three of them struck me as potentially not long for this world and I was 
> thinking if we needed/could deprecate them before any kind of ABI stability 
> set in.
> 
> I'm listing them here but it might be worth starting separate discussions for 
> each of them.
> 
> Final
> 
> Can someone tell me what is the use of 'final' now that we have 'public' 
> default to disallowing subclassing in importing modules? I know that 'final' 
> has the added constraint of disallowing subclassing in the same module, but 
> how useful is that? Does it hold its weight? Would we add it now if it did 
> not exist?

Final can be consumed (so to speak) by other types within the module. It's not 
strictly an in-module/out-of-module decision the way public and open are.

> Lazy
> 
> This one is clearer: if Joe Groff's property behaviors proposal from last 
> year is brought forward again, lazy can be demoted from a language keyword to 
> a Standard Library property behavior. If Joe or anybody from the core team 
> sees this: do we have any luck of having this awesome feature we 
> discussed/designed/implemented in the Swift 4 timeframe?

Groff!

> Fileprivate 
> 
> I started the discussion early during the Swift 4 timeframe that I regret the 
> change in Swift 3 which introduced a scoped private keyword. For me, it's not 
> worth the increase in complexity in access modifiers. I was very happy with 
> the file-scope of Swift pre-3. When discussing that, Chris Latner mentioned 
> we'd have to wait for Phase 2 to re-discuss it and also show proof that 
> people mostly used 'fileprivate' and not the new 'private' modifier as proof 
> if we want the proposal to have any weight. Does anybody have a good idea for 
> compiling stats from GitHub on this subject? First of all, I've always found 
> the GitHub Search quite bad and don't know how much it can be trusted. 
> Secondly, because 'private' in Swift 2 and 3 have different meanings, a 
> simple textual search might get us wrong results if we don't find a way to 
> filter on Swift 3 code.

I use both.

-- E, one data point

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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Matthew Johnson via swift-evolution]

> On Feb 13, 2017, at 11:28 AM, James Froggatt via swift-evolution 
>  wrote:
> 
> Having loosely followed this discussion, the way I'm thinking of ‘closed’ is 
> as a modifier which would let you switch over something from outside the 
> module in which it is declared.
> 
> From outside the declaring module:
> • A closed enum's cases can be exhaustively switched.
> • A closed protocol's conforming types can be exhaustively switched.
> • A closed class's subclasses can be exhaustively switched.
> 
> If this is correct, I can't help but think ‘closed’ is describing something 
> subtly different in each case - picking and choosing the ‘important’ 
> relationship for each type, while protocols already have a subtyping 
> relationship, and it sounds like there's possibility for enum subtyping in 
> the future.
> 
> I'd rather keep ‘open’ (and a potential future ‘closed’) purely describing 
> the subtyping relationship, and have some other means of labelling 
> conformance and cases as switchable.

I am drafting a manifesto-style document regarding value subtyping which will 
make it clear how value subtypes fit into the picture.  This document covers 
the relationship of enum cases with value subtyping and will show clearly how 
enum cases are analogous to subclasses.

> ___
> 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

Re: [swift-evolution] Simplifying Access Using 'Hidden'

[Dietmar Planitzer via swift-evolution]

The problem with fileprivate is this: a new keyword was introduced for the 
original definition of private and a new definition of private was introduced 
that does not carry its weight in the context of Swift. Because of these two 
actions, the original definition of private was elevated to a level above the 
private keyword which by the end of the day is just a very weak version of a 
sub-module / package access level.

The original definition of private made sense in the context of Swift 2 because:

1) it fit into the definition of public and internal: private is everything 
inside a file, internal is everything inside a module and public is the subset 
of internal stuff that we want to be accessible outside the module boundary. 
This was a straight-forward conceptual model.

2) it played well together with the Swift definition of an extension and it 
provided some relieve to the limitation that an extension can’t define a 
private stored property: e.g. I was able to define a type inside of a file by 
splitting it up into a base type definition which would carry all the private 
stored properties and a series of extensions which would define the semantics 
of the type, organized into logical blocks.

Now in Swift 3 I have to use fileprivate to pull off (2) and fileprivate adds 
extra complexity to (1) without given me the flexibility to:

a) add support for sub-modules. Sub-modules would require the addition of yet 
another access level.

b) put the implementation of separate but strongly related types into separate 
files. Eg in order to implement a module which has a set of SPI

What worries me is that I see more and more proposals that want to add yet 
another bunch of access levels and I also see the sub-module discussion come up 
from time to time. It also worries me that Swift already has more access levels 
than e.g. Java, yet it is Java that allows me to more precisely express my 
intent because:

I) I can express the intent that this function / type X is only relevant inside 
this package Y and nobody outside the package should be able to access X

II) I can express the intent that this function X should only be accessed by a 
subclass A of B, but not outside the subclassing context

I feel that the Swift access level story, as it stands today, is not only 
needless complicated compared to other languages while actually providing less 
relevant expressivity, it also feels like that the complexity of this story 
will sharply increase over time while still not providing much more relevant 
expressivity.

So IMO Swift should:

1) go back to public, internal and private with the respective definitions of 
Swift 2 (yes, open is another useless addition to the access level story but I 
frankly see less chance of getting rid of that compared to fileprivate)

2) then figure out whether and how to add sub-module capabilities. Add a module 
access level in this case and consider removing internal (with an alias 
internal == module as a back combat step)

3) then, and only then, consider adding additional levels if there is a clearly 
measurable advantage in doing so


Regards,

Dietmar Planitzer


> On Feb 13, 2017, at 08:21, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> People talk always like “I never liked fileprivate” and I feel like some of 
> you forgot that fileprivate is not new to Swift. It’s the repainted private 
> from days before Swift 3. I cannot recall anyone complaining about it that 
> much. There were some people that forced the addition of a stricter private 
> access modifier for Swift 3. Now that we have both, there are a lot of 
> complains about fileprivate.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 13. Februar 2017 um 17:10:45, Joanna Carter via swift-evolution 
> (swift-evolution@swift.org) schrieb:
> 
>> Le 13/02/2017 à 15:15, Adrian Zubarev via swift-evolution a écrit : 
>> 
>> > –1 
>> > 
>> > I won’t even try to be constructive on this one. It simply makes me 
>> > tired of all this access modifier mess. |open|, |closed|, |public|, 
>> > |internal|, now |hidden|, |fileprivate|, |directoryprivate|, 
>> > |moduleprivate|, |private|, I might even forget some of the proposed 
>> > access modifiers. 
>> > 
>> > Instead of adding new stuff that explodes the complexity we should put 
>> > our energy and fix existing issues, like the inconsistent |open| for 
>> > example. 
>> 
>> I would also say that access modifiers do seem to be be somewhat messy. 
>> 
>> I have never liked the idea of fileprivate ; this is the equivalent of 
>> Delphi's private scope, to which they then added strict private for class 
>> only scope. That was a similar mess. 
>> 
>> I am still not sure why we can't have the good old-fashioned visibilities of 
>> private, protected and public for classes. They have worked well for years 
>> and I feel we are changing things for change's sake. 
>> 
>> For all types other than classes, where inheritance is a 

Re: [swift-evolution] Strings in Swift 4

[Ronald Bell via swift-evolution]

> On Feb 10, 2017, at 12:38 PM, Hooman Mehr via swift-evolution 
>  wrote:
> 
> 
>> On Feb 9, 2017, at 6:50 PM, Shawn Erickson > > wrote:
>> 
>> 
>> 
>> On Thu, Feb 9, 2017 at 3:45 PM Hooman Mehr > > wrote:
>>> On Feb 9, 2017, at 3:11 PM, Dave Abrahams >> > wrote:
>>> 
>>> 
>>> on Thu Feb 09 2017, "Ted F.A. van Gaalen" >> > wrote:
>>> 
 Hello Shawn
 Just google with any programming language name and “string manipulation”
 and you have enough reading for a week or so :o)
 TedvG
>>> 
>>> That truly doesn't answer the question.  It's not, “why do people index
>>> strings with integers when that's the only tool they are given for
>>> decomposing strings?”  It's, “what do you have to do with strings that's
>>> hard in Swift *because* you can't index them with integers?”
>> 
>> I have done some string processing. I have not encountered any algorithm 
>> where an integer index is absolutely needed, but sometimes it might be the 
>> most convenient. 
>> 
>> For example, there are valid reasons to keep side tables that hold indexes 
>> into a string. (such as maintaining attributes that apply to a substring or 
>> things like pre-computed positions of soft line breaks). It does not require 
>> the index to be integer, but maintaining validity of those indexes after the 
>> string is mutated requires being able to offset them back or forth from some 
>> position on. These operations could be less verbose and easier if the index 
>> happens to be integer or (efficiently) supports + - operators. Also, I know 
>> there are other methods to deal with such things and mutating a large string 
>> generally is a bad idea, but sometimes it is the easiest and most convenient 
>> solution to the problem at hand.
>> 
>>  The end goal of this string is for human consumption right? So such 
>> manipulation would need need to unicode aware in the modern world? ..or is 
>> it for some other reason?
>> 
>> -Shawn
> 
> For an example of what I mean, see the source code of 
> NS(Mutable)AttributedString 
> 
>  and note how most of the mutating methods of Mutable variant are not 
> implemented yet...
> 
> So, a good example of where such indexing would be convenient, could be 
> writing a swift-native AttributedString backed by Swift native String.

On that last topic, NSAttributedString has always seemed like a strange design 
— a class with a bunch of attribute methods with a property that lets you 
interrogate the String behind it all. 

It always seemed to me that there was a false distinction. Strings should have 
optional properties, the way GameplayKit does GKEntities and GKComponents.

Simple Strings would return nil if you asked them for their attributes.

Attributed Strings would return attributes.

I think it would be a lot more intuitive how to parse an attributed string in 
blocks and then refer back to the attributes of each chunk, for one thing.

Is there a reason why composition was chosen to be the way it is in 
NSAttributedString, instead?

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

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

> On 11 Feb 2017, at 18:33, Dave Abrahams  wrote:
> 
> All of these examples should be efficiently and expressively handled by the 
> pattern matching API mentioned in the proposal. They definitely do not 
> require random access or integer indexing. 
> 
Hi Dave, 
then I am very interested to know how to unpack aString (e.g. read from a file 
record such as in the previous example:
123534-09EVXD4568,991234,89ABCYELLOW12AGRAINESYTEMZ3453 ) 
without using direct subscripting like str[n1…n2) ? 
(which btw is for me the most straightforward and ideal method) 
conditions:
   -The source string contains fields of known position (offset) and length, 
concatenated together
without any separators (like in a CSV)
  -the  contents of each field is unpredictable. 
   which excludes the use of pattern-matching. 
   -the source string needs to be unpacked in independent strings. 

I made this example: (the comments also stress my point) 
//: Playground - noun: a place outside the mean and harsh production environment
//   No presidents were harmed during the production of this example. 
import UIKit
import Foundation

// The following String extension with subscriptor "direct access"
// functionality, included in in almost each and every app I create,
// wouldn't be necessary if str[a.. String
{
guard i >= 0 && i < characters.count else { return "" }
return String(self[index(startIndex, offsetBy: i)])
}

subscript(range: Range) -> String
{
let lowerIndex = index(startIndex, offsetBy: max(0,range.lowerBound), 
limitedBy: endIndex) ?? endIndex
return substring(with: lowerIndex..<(index(lowerIndex, offsetBy: 
range.upperBound - range.lowerBound, limitedBy: endIndex) ?? endIndex))
}
 
subscript(range: ClosedRange) -> String
{
let lowerIndex = index(startIndex, offsetBy: max(0,range.lowerBound), 
limitedBy: endIndex) ?? endIndex
return substring(with: lowerIndex..<(index(lowerIndex, offsetBy: 
range.upperBound - range.lowerBound + 1, limitedBy: endIndex) ?? endIndex))
}
}
// In the following example, the record's field positions and lengths are fixed 
format
// and will never change.
// Also, the record's contents has been validated completely by the sending 
application.

// Normally it is an input record, read from a storage medium,
// however for the purpose of this example it is defined here:

let record = "123A.534.CMCU3Arduino Due Arm 32-bit Micro controller.  
000341000568002250$"

// Define a product data structure:
struct Product
{
var id :String // is key
var group: String
var name: String
var description : String
var inStock: Int
var ordered : Int
var price: Int// in cents: no Money data type in Swift available.
var currency: String

// of course one could use "set/get" properties here
// which could validate the input to this structure.

var priceFormatted: String  // computed property.
{
get
{
let whole = (price / 100)
let cents = price - (whole * 100)
return currency + " \(whole).\(cents)"
}
}

// TODO: disable other default initiators.
init(inputrecord: String)
{
   id  = inputrecord[ 0..<10]
   group   = inputrecord[10..<14]
   name= inputrecord[14..<30]
   description = inputrecord[30..<60]
   inStock = Int(inputrecord[60..<70])!
   ordered = Int(inputrecord[70..<80])!
   price   = Int(inputrecord[80..<90])!
   currency= inputrecord[90]
}

// Add necessary business and DB logic for products here.
}


func test()
{
let product = Product(inputrecord: record)

print("=== Product data for the item with ID: \(product.id) ")
print("ID : \(product.id)")
print("group  : \(product.group)")

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Zach Waldowski via swift-evolution]

I still haven't been convinced by this. What are these incredibly large
files that people are dealing with, and why should a crucial feature of
the language be built around servicing anti patterns?


Zachary



On Mon, Feb 13, 2017, at 01:26 PM, William Sumner via swift-evolution wrote:
> 

>> On Feb 12, 2017, at 9:19 AM, David Hart via swift-evolution > evolut...@swift.org> wrote:
>> 

>> 

>> *Fileprivate* 

>> 

>> I started the discussion early during the Swift 4 timeframe that I
>> regret the change in Swift 3 which introduced a scoped private
>> keyword. For me, it's not worth the increase in complexity in access
>> modifiers. I was very happy with the file-scope of Swift pre-3. When
>> discussing that, Chris Latner mentioned we'd have to wait for Phase 2
>> to re-discuss it and also show proof that people mostly used
>> 'fileprivate' and not the new 'private' modifier as proof if we want
>> the proposal to have any weight. Does anybody have a good idea for
>> compiling stats from GitHub on this subject? First of all, I've
>> always found the GitHub Search quite bad and don't know how much it
>> can be trusted. Secondly, because 'private' in Swift 2 and 3 have
>> different meanings, a simple textual search might get us wrong
>> results if we don't find a way to filter on Swift 3 code.
> 

> I find the “Motivation” section of SE-0025 convincing.
> Private/fileprivate allows for distinguishing between shared and
> hidden details among related code in a file. Not only is there benefit
> in knowing intent when reading, but there is also benefit in writing
> because the IDE won’t autocomplete hidden details. I work on large
> files I’m not the sole author of, so this is important to me.
> 

> Preston

> _

> 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

Re: [swift-evolution] final + lazy + fileprivate modifiers

[William Sumner via swift-evolution]

> On Feb 13, 2017, at 11:40 AM, Zach Waldowski via swift-evolution 
>  wrote:
> 
> I still haven't been convinced by this. What are these incredibly large files 
> that people are dealing with, and why should a crucial feature of the 
> language be built around servicing anti patterns?
> 
> Zachary


I consider a 500+ line file to be large (cognitively “larger” if I didn’t write 
it). Your definition may vary. In Swift 2, hiding details required separating 
classes by file, which conflicts with the common practice of grouping related 
classes in one file. I think SE-0025 was an important addition to the language.

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

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Matthew Johnson via swift-evolution]

> On Feb 13, 2017, at 12:40 PM, Zach Waldowski via swift-evolution 
>  wrote:
> 
> I still haven't been convinced by this. What are these incredibly large files 
> that people are dealing with, and why should a crucial feature of the 
> language be built around servicing anti patterns?

I agree that it is usually better to avoid having files get too large.  But 
large is relative and subject.  My 27” iMac displays about 100 lines of code at 
a time in Xcode.  `private` can be useful any time you go much beyond that - it 
can help you know that you’re looking at all of the relevant code.  Files in 
the 5-600 line range are pretty common and `private` can become quite useful 
once you start getting to getting that many lines in a file.  Of course this is 
an opinion so your mileage may vary.

> 
> Zachary
> 
> On Mon, Feb 13, 2017, at 01:26 PM, William Sumner via swift-evolution wrote:
>> 
>>> On Feb 12, 2017, at 9:19 AM, David Hart via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> Fileprivate 
>>> 
>>> I started the discussion early during the Swift 4 timeframe that I regret 
>>> the change in Swift 3 which introduced a scoped private keyword. For me, 
>>> it's not worth the increase in complexity in access modifiers. I was very 
>>> happy with the file-scope of Swift pre-3. When discussing that, Chris 
>>> Latner mentioned we'd have to wait for Phase 2 to re-discuss it and also 
>>> show proof that people mostly used 'fileprivate' and not the new 'private' 
>>> modifier as proof if we want the proposal to have any weight. Does anybody 
>>> have a good idea for compiling stats from GitHub on this subject? First of 
>>> all, I've always found the GitHub Search quite bad and don't know how much 
>>> it can be trusted. Secondly, because 'private' in Swift 2 and 3 have 
>>> different meanings, a simple textual search might get us wrong results if 
>>> we don't find a way to filter on Swift 3 code.
>> 
>> 
>> I find the “Motivation” section of SE-0025 convincing. Private/fileprivate 
>> allows for distinguishing between shared and hidden details among related 
>> code in a file. Not only is there benefit in knowing intent when reading, 
>> but there is also benefit in writing because the IDE won’t autocomplete 
>> hidden details. I work on large files I’m not the sole author of, so this is 
>> important to me.
>> 
>> Preston
>> ___
>> 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

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

Re: [swift-evolution] final + lazy + fileprivate modifiers

[William Sumner via swift-evolution]

> On Feb 12, 2017, at 9:19 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
> Fileprivate 
> 
> I started the discussion early during the Swift 4 timeframe that I regret the 
> change in Swift 3 which introduced a scoped private keyword. For me, it's not 
> worth the increase in complexity in access modifiers. I was very happy with 
> the file-scope of Swift pre-3. When discussing that, Chris Latner mentioned 
> we'd have to wait for Phase 2 to re-discuss it and also show proof that 
> people mostly used 'fileprivate' and not the new 'private' modifier as proof 
> if we want the proposal to have any weight. Does anybody have a good idea for 
> compiling stats from GitHub on this subject? First of all, I've always found 
> the GitHub Search quite bad and don't know how much it can be trusted. 
> Secondly, because 'private' in Swift 2 and 3 have different meanings, a 
> simple textual search might get us wrong results if we don't find a way to 
> filter on Swift 3 code.

I find the “Motivation” section of SE-0025 convincing. Private/fileprivate 
allows for distinguishing between shared and hidden details among related code 
in a file. Not only is there benefit in knowing intent when reading, but there 
is also benefit in writing because the IDE won’t autocomplete hidden details. I 
work on large files I’m not the sole author of, so this is important to me.

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

Re: [swift-evolution] Simplifying Default Access Modifiers

[Adrian Zubarev via swift-evolution]

–1 for me.

IMO the current behavior reduces all that internal noise in large projects, 
where the author only makes a small part of the API public. Furthermore this 
will break the implicit initializer on structs and make it implicitly public. 
Leaving the initializer as internal while everything else is public as a 
workaround would be inconsistent solution, so that’s a no go. Personally I 
think that will introduce more noise than the current behavior, because we’ll 
have to repeat internal all over the place in large projects. So in my eyes 
this would be a regression.

P.S.: I’m curious what the core team has to say about this.



-- 
Adrian Zubarev
Sent with Airmail

Am 13. Februar 2017 um 10:02:39, Jonathan Hull via swift-evolution 
(swift-evolution@swift.org) schrieb:

I would like to propose a change to the default access modifier within an 
enclosing scope. The default for top level definitions would stay internal, but 
anything within a scope would by default have the same visibility as it’s 
enclosing scope.

The main reason for this is readability/maintainability, and having the 
intention clearly stand out. It would also reduce a great amount of 
boilerplate. It also matches the mental model of how scopes normally work 
regarding inheritance of visibility/properties (which means less to teach 
newbies).

Right now if I want to make a type and all of it’s vars/methods public, I have 
to mark each individual var/method public, which leads to a lot of 
boilerplate/noise and makes everything harder to read:

public struct MyStruct {
public var a:Int
public var b:Int
private var c:Int
public var d:Int
}

Notice that the private var doesn’t really stand out as such very well. Also, 
it is exceedingly rare (at least in my own coding style) that I actually want 
an internal variable unless the type itself is internal, and in those cases, I 
would like that choice to stand out as deliberate the same way I want ‘private' 
to stand out. As it stands, I wait until I think I am done modifying a type to 
mark it public because of the extra noise generated. I also make a point to 
write ‘internal' for things that I explicitly want to restrict to internal.

Consider the alternative:

public struct MyStruct {
var a:Int
var b:Int
private var c:Int
var d:Int
}

Now the fact that I have chosen to make ‘c’ private really stands out much 
better. When revisiting the code in 6 months, the struct is much more 
“glance-able” (as a friend of mine likes to say).

Note also the nuance that I didn’t say that those vars were marked public (or 
had the same modifier), I said that they had the SAME VISIBILITY as the 
enclosing scope (which in this case happens to be public). This is a concept 
which is hard to express currently, and IIRC this is what we had to do to make 
the edge cases of swift 3’s private modifier work properly.  

Basically, it already works this way for ‘private’, ‘fileprivate’, & 
‘internal’, just not for ‘public’ or ‘open’… which can be surprising, 
especially since you don’t discover these differences until you are working 
across modules. We should just extend that mental model up to include public 
and open. Migration would just take internal variables of public/open types and 
mark them explicitly with the word ‘internal'.

Thanks,
Jon

___
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

Re: [swift-evolution] Simplifying Default Access Modifiers

[David Goodine via swift-evolution]

I think having a different default access for nested-scope adds a significant 
amount of cognitive complexity for not much value.  I understand that structs 
as nested types are often used to communicate values outside the score 
(internal even), so public will be required often in these cases.  But, then 
the question is what about structs that are purely for internal use, which 
happens just as often? Or classes?

Furthermore, you can achieve the same level of clarity without source-breaking 
changes to the language simply by better code organization, as in:

public struct MyStruct {
public var a:Int
public var b:Int
public var d:Int

private var c:Int
}

-d


> On Feb 13, 2017, at 4:02 AM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> I would like to propose a change to the default access modifier within an 
> enclosing scope.  The default for top level definitions would stay internal, 
> but anything within a scope would by default have the same visibility as it’s 
> enclosing scope.
> 
> The main reason for this is readability/maintainability, and having the 
> intention clearly stand out.  It would also reduce a great amount of 
> boilerplate.  It also matches the mental model of how scopes normally work 
> regarding inheritance of visibility/properties (which means less to teach 
> newbies).
> 
> Right now if I want to make a type and all of it’s vars/methods public, I 
> have to mark each individual var/method public, which leads to a lot of 
> boilerplate/noise and makes everything harder to read:
> 
>   public struct MyStruct {
>   public var a:Int
>   public var b:Int
>   private var c:Int
>   public var d:Int
>   }
> 
> Notice that the private var doesn’t really stand out as such very well.  
> Also, it is exceedingly rare (at least in my own coding style) that I 
> actually want an internal variable unless the type itself is internal, and in 
> those cases, I would like that choice to stand out as deliberate the same way 
> I want ‘private' to stand out.  As it stands, I wait until I think I am done 
> modifying a type to mark it public because of the extra noise generated.  I 
> also make a point to write ‘internal' for things that I explicitly want to 
> restrict to internal.
> 
> Consider the alternative:
> 
>   public struct MyStruct {
>   var a:Int
>   var b:Int
>   private var c:Int
>   var d:Int
>   }
> 
> Now the fact that I have chosen to make ‘c’ private really stands out much 
> better.  When revisiting the code in 6 months, the struct is much more 
> “glance-able” (as a friend of mine likes to say).
> 
> Note also the nuance that I didn’t say that those vars were marked public (or 
> had the same modifier), I said that they had the SAME VISIBILITY as the 
> enclosing scope (which in this case happens to be public).  This is a concept 
> which is hard to express currently, and IIRC this is what we had to do to 
> make the edge cases of swift 3’s private modifier work properly.  
> 
> Basically, it already works this way for ‘private’, ‘fileprivate’, & 
> ‘internal’, just not for ‘public’ or ‘open’… which can be surprising, 
> especially since you don’t discover these differences until you are working 
> across modules.  We should just extend that mental model up to include public 
> and open.  Migration would just take internal variables of public/open types 
> and mark them explicitly with the word ‘internal'.
> 
> Thanks,
> Jon
> 
> ___
> 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

Re: [swift-evolution] Simplifying Default Access Modifiers

[Karl Wagner via swift-evolution]

> On 13 Feb 2017, at 14:24, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> –1 for me.
> 
> IMO the current behavior reduces all that internal noise in large projects, 
> where the author only makes a small part of the API public. Furthermore this 
> will break the implicit initializer on structs and make it implicitly public. 
> Leaving the initializer as internal while everything else is public as a 
> workaround would be inconsistent solution, so that’s a no go. Personally I 
> think that will introduce more noise than the current behavior, because we’ll 
> have to repeat internal all over the place in large projects. So in my eyes 
> this would be a regression.
> 
> P.S.: I’m curious what the core team has to say about this.
> 
I actually think “internal” is something which is worth calling out explicitly. 
It says that something is visible to other types in the project but not 
generally exported as part of the library’s API, which isn’t necessarily 
obvious. Implicit initialisers can be defined as having the same visibility as 
the type which they initialise.

Would be a huge source-breaking change though. I’m not sure anybody’s really 
100% happy with our access modifiers, but it’s such a big change the core-team 
would understandably be reluctant to do it.

- Karl


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

Re: [swift-evolution] [swift-users] for in? optionalCollection {

[Tino Heth via swift-evolution]

> This would be more easily done than new syntax, surely.
… and it wouldn't increase the size of the language, so in general, I prefer 
library-solutions.

I'd expect some pushback against the conformance, but my personal opinion is 
that the difference between an empty collection and a missing collection 
doesn't matter most of the time.

Performance doesn't matter most of the time as well ;-), but imho it's a big 
plus if the most elegant solution is the fastest, too (and I have no idea if or 
when the compiler infrastructure is clever enough to recognise empty loops 
without instantiating useless objects).

But afaics, there is some consensus that Optional deserves some sugar 
applied to it — either in the language, or in the stdlib.

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