Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 12 Apr 2017, at 01:18, Jakub Suder via swift-evolution 
>  wrote:
> 
> I'm honestly having trouble believing that this is being seriously 
> proposed... I always saw type inference as one of the most important 
> advantages of Swift over some older languages, the Swift ebook mentions many 
> times how smart Swift is that it can infer types for you so that you don't 
> have to type too much boilerplate.

I think Swift and its compiler have. A lot of other strong points beyond type 
inference and emphasis on static typing too, but type inference has a very very 
real cost and sooner or later the language and its community will have to deal 
with compile times that are a lot slower (some people were reporting about 2+ 
times slower) than a similar project in Objective-C... that is a very real 
productivity cost.

> And here we're talking about removing this feature that was advertised from 
> the beginning as Swift's strong point, in order to make the compilation 
> faster? The compiler speeds will be improved, the syntax will stay with us.
> 
> Yes, specifying the type is often clearer, I do it myself, e.g. "var enabled: 
> Bool = true". But that's my choice, not something I should be forced to do. 
> It's something to put in style guides, not to enforce with the compiler.
> 
> 
>> On 8 April 2017 at 07:40, Pranshu Goyal via swift-evolution 
>>  wrote:
>> I agree with the sentiment of the proposal, it does add value to overall 
>> efficiency of swift and make things simpler for the swift team, but as 
>> Matthew said a blanket ban will add noise to the code. Also this particular 
>> feature is one of those niceties about swift which makes it very welcoming 
>> to new adopters.
>> 
>> If some middle ground can be proposed to this problem then I think we will 
>> be making a lot of people happy.
>> 
>>> On 7 April 2017 at 18:31, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> > On Apr 7, 2017, at 2:21 AM, Daniel Duan via swift-evolution 
>>> >  wrote:
>>> >
>>> > Hi all,
>>> >
>>> > In a discussion about inferring parameter types from default value, Slava 
>>> > brought up some performance problems caused by type inference for stored 
>>> > properties in side types:
>>> >
>>> > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
>>> >
>>> > Towards the end, the post mentioned that some Swift team members 
>>> > contemplated requiring types for stored properties in type declarations. 
>>> > I think this idea deserves some more attention. Hence this last minute 
>>> > idea-floating.
>>> >
>>> > In addition to solving a performance headache in implementation, there're 
>>> > always the general benefit of making type declartion more explicit and 
>>> > readable (clarity for reader should out-weigh pleasure of the author). 
>>> > Making the
>>> > language slightly more consistent (we are not inferring types for default 
>>> > parameter values in function anyways).
>>> >
>>> > The cons for doing this are obvious too: the inference makes the language 
>>> > feels more friendly and is, undoubtedly, a beloved feature for many. This 
>>> > would be a source breaking change.
>>> >
>>> > Just thought I'd float the idea to gather some quick reaction. What do 
>>> > y'all think?
>>> 
>>> I’m willing to keep an open mind on this topic but I don’t think wholesale 
>>> banning of inference is the right thing to do.  Here is an example of a 
>>> case where I do not want to give up inference.  When a property is 
>>> initialized inline by calling an initializer of a non-generic type (very 
>>> common) any annotation is strictly redundant.
>>> 
>>> struct {
>>> let foo = Foo()
>>> }
>>> 
>>> Requiring a type annotation here feels very unnecessary and boilerplate-y.  
>>> I adds no additional clarity to a reader of the code, only noise.  Noise 
>>> reduces clarity.  Small amounts of unnecessary or redundant information 
>>> such as in an individual stored property declaration are not that big a 
>>> deal.  But on balance they add up quickly and have an undesirable impact on 
>>> the overall clarity of code.
>>> 
>>> >
>>> > Daniel Duan
>>> > ___
>>> > 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
>> 
>> 
>> 
>> -- 
>> Pranshu Goyal
>> iOS Developer
>> tlkn
>> 
>> ___
>> 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

Re: [swift-evolution] Enhancing access levels without breaking changes

[David Hart via swift-evolution]

> On 12 Apr 2017, at 07:42, Chris Lattner  wrote:
> 
> On Apr 11, 2017, at 10:30 PM, David Hart  > wrote:
>>> To me, the reason for limiting it to a file is about predictability, the 
>>> ability to locally reason about a type, and the need to define some 
>>> boundary (for symbol visibility reasons).  Saying that extensions to a type 
>>> have access to private members if they are in the same module is just as 
>>> arbitrary as limiting it to a single file, and a whole lot less useful from 
>>> the “reasoning about a type” perspective.
>> 
>> I think you misunderstand. We were talking about two extensions of a type, 
>> in a different file from the type, to share private members between 
>> themselves.
>> 
>> Doug Gregor mentioned it during the PR process and we added an example to 
>> disallow it, but in hindsight, I think it should be allowed.
> 
> Ah, you’re saying:
> 
> a.swift:
> struct X {}
> 
> b.swift:
> extension X {
>   private func f() {}
> }
> 
> extension X {
>   func g() { f() }
> }
> 
> If so, then yes, I agree we should accept that.
> 
> -Chris

Should we edit the proposal or let the Core Team fix it during review as John 
suggests?

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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Chris Lattner via swift-evolution]

On Apr 11, 2017, at 10:30 PM, David Hart  wrote:
>> To me, the reason for limiting it to a file is about predictability, the 
>> ability to locally reason about a type, and the need to define some boundary 
>> (for symbol visibility reasons).  Saying that extensions to a type have 
>> access to private members if they are in the same module is just as 
>> arbitrary as limiting it to a single file, and a whole lot less useful from 
>> the “reasoning about a type” perspective.
> 
> I think you misunderstand. We were talking about two extensions of a type, in 
> a different file from the type, to share private members between themselves.
> 
> Doug Gregor mentioned it during the PR process and we added an example to 
> disallow it, but in hindsight, I think it should be allowed.

Ah, you’re saying:

a.swift:
struct X {}

b.swift:
extension X {
  private func f() {}
}

extension X {
  func g() { f() }
}

If so, then yes, I agree we should accept that.

-Chris







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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Chris Lattner via swift-evolution]

> On Apr 10, 2017, at 12:28 PM, John McCall via swift-evolution 
>  wrote:
> 
>> Speaking just for myself, I don't think we'd accept such a change purely for 
>> aesthetics;
>> 
>> If I recall correctly, Chris in post-review discussions communicated that a 
>> new keyword to replace `fileprivate` would be considered if `fileprivate` 
>> turned out to be commonly used enough to be aesthetically problematic?
> 
> Yes.  We would consider it.  Chris probably believes that we're more likely 
> to accept that change than I do; that's why I was careful to say that I was 
> just speaking for myself.  (Chris didn't need to say that explicitly in his 
> message because he wasn't explicitly speaking for the Core Team in other 
> parts.)

FWIW, there is a temporal aspect to this.  1-2 weeks ago, I was more open to 
the discussion about renaming fileprivate.  However, as of the core team 
meeting last week, it became clear that the priority of maintaining source 
stability (and thus, not massively thrashing source files in the 3->4 
conversion) is an overriding concern.

As such, it is clear that changing fileprivate isn’t going to happen.  This is 
the direct sequence of events that led to 0169 being proposed.

-Chris

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

Re: [swift-evolution] Enhancing access levels without breaking changes

[David Hart via swift-evolution]

> On 12 Apr 2017, at 07:16, Chris Lattner  wrote:
> 
> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
>  wrote:
 I understand what you are saying and I wouldn't be against relaxing that 
 requirement (not talking for Chris here).
 
 The model would change from "Types share scopes with their extensions in 
 the same file the type was defined" to "Types and their extensions share 
 the same scope in each file".
>>> 
>>> Oh, I had missed that somehow.  I agree that that is a very strange rule.  
>>> Do you know why it was proposed that way?
>> 
>> We had to take a stance and Chris seemed to prefer the rule that was 
>> proposed. I didn't press because I'm sure he has reasons for preferring it 
>> that way. But I have a preference for generalizing visibility to all 
>> extensions, even to those in a different file than the type.
> 
> To me, the reason for limiting it to a file is about predictability, the 
> ability to locally reason about a type, and the need to define some boundary 
> (for symbol visibility reasons).  Saying that extensions to a type have 
> access to private members if they are in the same module is just as arbitrary 
> as limiting it to a single file, and a whole lot less useful from the 
> “reasoning about a type” perspective.

I think you misunderstand. We were talking about two extensions of a type, in a 
different file from the type, to share private members between themselves.

Doug Gregor mentioned it during the PR process and we added an example to 
disallow it, but in hindsight, I think it should be allowed.

> Expanding it beyond a module would require a ton of stuff to be exported that 
> otherwise wouldn’t be, and would defeat a ton of optimization potential that 
> we can’t accept.
> 
> -Chris
> 

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

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[David Hart via swift-evolution]

> On 12 Apr 2017, at 02:50, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Tue, Apr 11, 2017 at 7:32 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via swift-evolution 
>>>  wrote:
>>> 
>>> That’s also the example that kept me thinking for a while.
>>> 
>>> Overall the proposal is a great compromise to some issues I had with the 
>>> first version. However I have a few more questions:
>>> 
>>> Why can’t we make it consistent and let the compiler add a new line after 
>>> the starting delimiter.
>>> 
>>> let string = """↵
>>> Swift↵
>>> """
>>> 
>>> // result
>>> ↵Swift↵
>>> If one would would the behavior from the proposal it’s really easy to add a 
>>> backslash after the starting delimiter.
>>> 
>>> 
>>> let string = """\↵
>>> Swift\↵
>>> """
>>> 
>>> // result
>>> Swift
>>> This would be consistent and less confusing to learn.
>>> 
>> That would mean that code like this:
>> 
>>  print("""
>>  A whole bunch of 
>>  multiline text
>>  """)
>>  print("""
>>  A whole bunch more 
>>  multiline text
>>  """)
>> 
>> Will print (with - to indicate blank lines):
>> 
>>  -
>>  A whole bunch of
>>  multiline text
>>  -
>>  -
>>  A whole bunch more
>>  multiline text
>>  -
>> 
>> This is, to a first approximation, never what you actually want the computer 
>> to do.
> 
> Brent, excellent job revising the proposal text. My question for you and the 
> other authors is the other way around: what is the rationale behind only 
> stripping the leading newline and not the trailing newline? While in many 
> cases a trailing newline is not harmful or even beneficial, if you trim the 
> one, wouldn't it make sense to trim the other? Wouldn't it make the rules 
> easier to explain to users too? For instance:
> 
> '''
> Hello, world!
> '''
> 
> could instead be a one-line string "Hello, world!"
> 
> And those who need the trailing newline can trivially insist on it:
> 
> '''
> Hello, world!
> 
> '''

I second Xiaodi's remark. I would prefer it if the trailing new line was 
escaped too. It would make more sense and is what people would logically expect 
IMHO.
>>> Can’t we make the indent algorithm work like this instead?
>>> let string = """\↵
>>> ↵
>>> ··content text↵
>>> """ // Indent starts with the first non space character
>>> 
>>> // result
>>> 
>>> ↵
>>> ··content text↵
>>> 
>>> The line where the closing delimiter is trims all space chapters and the 
>>> indent for the whole multi-line string is starting at the point where the 
>>> first non-space chapters is in that line.
>>> 
>> 
>> We could; I discuss that briefly in the very last section, on alternatives 
>> to the indentation stripping we specify:
>> 
>>  • Stripping indentation to match the depth of the least indented line: 
>> Instead of removing indentation to match the end delimiter, you remove 
>> indentation to match the least indented line of the string itself. The issue 
>> here is that, if all lines in a string should be indented, you can't use 
>> indentation stripping. Ruby 2.3 does this with its heredocs, and Python's 
>> dedent function also implements this behavior.
>> 
>> That doesn't quite capture the entire breadth of the problem with this 
>> algorithm, though. What you'd like to do is say, "all of these lines are 
>> indented four columns, so we should remove four columns of indentation from 
>> each line". But you don't have columns; you have tabs and spaces, and 
>> they're incomparable because the compiler can't know what tab stops you set. 
>> So we'd end up calculating a common prefix of whitespace for all lines and 
>> removing that. But that means, when someone mixes tabs and spaces 
>> accidentally, you end up stripping an amount of indentation that is 
>> unrelated to anything visible in your code. We could perhaps emit a warning 
>> in some suspicious circumstances (like "every line has whitespace just past 
>> the end of indentation, but some use tabs and others use spaces"), but if we 
>> do, we can't know which one is supposed to be correct. With the proposed 
>> design, we know what's correct—the last line—and any deviation from it can 
>> be flagged *at the particular line which doesn't match our expectation*.
>> 
>> Even without the tabs and spaces issue, consider the case where you 
>> accidentally don't indent a line far enough. With your algorithm, that's 
>> indistinguishable from wanting the other lines to be indented more than that 
>> one, so we generate a result you don't want and we don't (can't!) emit a 
>> warning to point out the mistake. With the proposed algorithm, we can notice 
>> there's an error and point to the line at fault.
>> 
>> Having the closing delimiter always be on its own line and using it to 
>> decide how much whitespace to strip is better because it gives the compiler 
>> a firm baseline to wor

Re: [swift-evolution] Enhancing access levels without breaking changes

[Chris Lattner via swift-evolution]

> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution 
>  wrote:
> 
> I don't want to make any change until Chris has been able to chime in. If he 
> agrees with us, what should be done?

The rationale here is to propose the minimal thing that improves the (bad) 
access control situation we have today, while leaving open this direction for 
future discussion.

I’m trying to factor potentially large N*M controversy into N+M controversy.

-Chris

> 
> • Immediate change in the proposal?
> • Would it have to go through a new review?
> • Or can the Core Team make the change if it is accepted?
> 
> On 11 Apr 2017, at 19:01, John McCall  > wrote:
> 
>> 
>>> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
>>> 
>>> On 11 Apr 2017, at 16:27, Matthew Johnson >> > wrote:
>>> 
 
 
 Sent from my iPad
 
 On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
> 
>> On 11 Apr 2017, at 13:29, Jonathan Hull > > wrote:
>> 
>>> 
>>> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> On 11 Apr 2017, at 09:40, John McCall >> > wrote:
>>> 
> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> Sent from my iPhone
> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> I have not voted in favor or against the proposal. I have been 
>> reading a lot of responses but I agree with Tony. 
>> 
>> When I started reading the proposal everything was more or less fine 
>> half way through the proposal because it was reverting private to 
>> fileprivate between the type and its extensions within the same 
>> file. I said, if you think of the type and its extensions as a unit 
>> then it makes sense. I can explain that. 
>> 
>> Then it started describing a different behavior among the extensions 
>> located in a file separate from the file containing the definition 
>> of the type. That just started a whole debate inside my head and I 
>> understand the passionate responses on both sides. 
>> 
>> But then I imagined myself explaining this to someone new to Swift 
>> and it just doesn't seem right. If it becomes convoluted then that's 
>> a red flag that it does not belong in Swift. 
> 
> I understand what you are saying and I wouldn't be against relaxing 
> that requirement (not talking for Chris here).
> 
> The model would change from "Types share scopes with their extensions 
> in the same file the type was defined" to "Types and their extensions 
> share the same scope in each file".
 
 Oh, I had missed that somehow.  I agree that that is a very strange 
 rule.  Do you know why it was proposed that way?
>>> 
>>> We had to take a stance and Chris seemed to prefer the rule that was 
>>> proposed. I didn't press because I'm sure he has reasons for preferring 
>>> it that way. But I have a preference for generalizing visibility to all 
>>> extensions, even to those in a different file than the type.
>> 
>> I think there is a technical limitation if the visibility goes beyond 
>> the compilation unit (unless whole module optimization is turned on).
> 
> I’m not suggesting visibility beyond the compilation unit. That would 
> break the hierarchy of visibility layers: accessibility levels have 
> always been contained in one-another and that’s why you can go from 
> private, to fileprivate, to internal, to public, to open (but not the 
> other way round) without the risk of any compilation error. If all scopes 
> of a type were visible to each other (whatever the file), you could not 
> go from private to fileprivate.
> 
> I’m talking about extensions of the same type in the same file (but in a 
> separate file from the type) to be able to share private members:
> 
> Type.swift
> 
> struct A {
> }
> 
> Other.swift
> 
> extension A {
> func foo() {
> bar()
> }
> }
> 
> extension A {
> private func bar() {
> }
> }
> 
 
 If this is not how your proposal already works I missed that aspect 
 earlier and find it extremely perplexing (which is probably why I missed 
 it).
>>> 
>>> It's mentioned in the Derailed design section:
>>> 
>>> This proposal does not change the behavior of extensions that are not in 
>>> th

Re: [swift-evolution] Enhancing access levels without breaking changes

[Chris Lattner via swift-evolution]

On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
 wrote:
>>> I understand what you are saying and I wouldn't be against relaxing that 
>>> requirement (not talking for Chris here).
>>> 
>>> The model would change from "Types share scopes with their extensions in 
>>> the same file the type was defined" to "Types and their extensions share 
>>> the same scope in each file".
>> 
>> Oh, I had missed that somehow.  I agree that that is a very strange rule.  
>> Do you know why it was proposed that way?
> 
> We had to take a stance and Chris seemed to prefer the rule that was 
> proposed. I didn't press because I'm sure he has reasons for preferring it 
> that way. But I have a preference for generalizing visibility to all 
> extensions, even to those in a different file than the type.

To me, the reason for limiting it to a file is about predictability, the 
ability to locally reason about a type, and the need to define some boundary 
(for symbol visibility reasons).  Saying that extensions to a type have access 
to private members if they are in the same module is just as arbitrary as 
limiting it to a single file, and a whole lot less useful from the “reasoning 
about a type” perspective.  

Expanding it beyond a module would require a ton of stuff to be exported that 
otherwise wouldn’t be, and would defeat a ton of optimization potential that we 
can’t accept.

-Chris

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Jaden Geller via swift-evolution]

> On Apr 7, 2017, at 4:07 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> On 07.04.2017 10:21, Daniel Duan via swift-evolution wrote:
>> Hi all,
>> 
>> In a discussion about inferring parameter types from default value,
>> Slava brought up some performance problems caused by type inference for
>> stored properties in side types:
>> 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
>> 
>> Towards the end, the post mentioned that some Swift team members
>> contemplated requiring types for stored properties in type declarations.
>> I think this idea deserves some more attention. Hence this last minute
>> idea-floating.
>> 
>> In addition to solving a performance headache in implementation,
>> there're always the general benefit of making type declartion more
>> explicit and readable (clarity for reader should out-weigh pleasure of
>> the author). Making the language slightly more consistent (we are not
>> inferring types for default parameter values in function anyways).
>> 
>> The cons for doing this are obvious too: the inference makes the
>> language feels more friendly and is, undoubtedly, a beloved feature for
>> many. This would be a source breaking change.
>> 
>> Just thought I'd float the idea to gather some quick reaction. What do
>> y'all think?
> 
> Although it seems like only an implementation-side problem(i.e. "let's just 
> improve implementation"), I see a benefits to require type for stored 
> property *if* it is not obvious what the type is for *reader*. I.e. if we 
> have something like this, I don't think we should require a type:
> struct S {
>  var x = 0
> }

I think there is value in requiring a type annotation there. For example, this 
bug would be avoided: https://twitter.com/benjaminencz/status/851892622213783552

> 
> but I do think it will be better to require a type in such cases :
> 
> struct S{
>  var x = something(SomeType(), 123, "123") // can be generic func
> }
> 
> 
> 
>> 
>> Daniel Duan ___
>> 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] [Pitch] Remove type-inference for stored property

[John McCall via swift-evolution]

> On Apr 11, 2017, at 8:18 PM, Jakub Suder via swift-evolution 
>  wrote:
> 
> I'm honestly having trouble believing that this is being seriously 
> proposed... I always saw type inference as one of the most important 
> advantages of Swift over some older languages, the Swift ebook mentions many 
> times how smart Swift is that it can infer types for you so that you don't 
> have to type too much boilerplate. And here we're talking about removing this 
> feature that was advertised from the beginning as Swift's strong point, in 
> order to make the compilation faster? The compiler speeds will be improved, 
> the syntax will stay with us.
> 
> Yes, specifying the type is often clearer, I do it myself, e.g. "var enabled: 
> Bool = true". But that's my choice, not something I should be forced to do. 
> It's something to put in style guides, not to enforce with the compiler.

To be clear, it's being "seriously proposed" in the sense that someone sent an 
email to a mailing list.

John.

> 
> 
> On 8 April 2017 at 07:40, Pranshu Goyal via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> I agree with the sentiment of the proposal, it does add value to overall 
> efficiency of swift and make things simpler for the swift team, but as 
> Matthew said a blanket ban will add noise to the code. Also this particular 
> feature is one of those niceties about swift which makes it very welcoming to 
> new adopters.
> 
> If some middle ground can be proposed to this problem then I think we will be 
> making a lot of people happy.
> 
> On 7 April 2017 at 18:31, Matthew Johnson via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> > On Apr 7, 2017, at 2:21 AM, Daniel Duan via swift-evolution 
> > mailto:swift-evolution@swift.org>> wrote:
> >
> > Hi all,
> >
> > In a discussion about inferring parameter types from default value, Slava 
> > brought up some performance problems caused by type inference for stored 
> > properties in side types:
> >
> > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> >  
> > 
> >
> > Towards the end, the post mentioned that some Swift team members 
> > contemplated requiring types for stored properties in type declarations. I 
> > think this idea deserves some more attention. Hence this last minute 
> > idea-floating.
> >
> > In addition to solving a performance headache in implementation, there're 
> > always the general benefit of making type declartion more explicit and 
> > readable (clarity for reader should out-weigh pleasure of the author). 
> > Making the
> > language slightly more consistent (we are not inferring types for default 
> > parameter values in function anyways).
> >
> > The cons for doing this are obvious too: the inference makes the language 
> > feels more friendly and is, undoubtedly, a beloved feature for many. This 
> > would be a source breaking change.
> >
> > Just thought I'd float the idea to gather some quick reaction. What do 
> > y'all think?
> 
> I’m willing to keep an open mind on this topic but I don’t think wholesale 
> banning of inference is the right thing to do.  Here is an example of a case 
> where I do not want to give up inference.  When a property is initialized 
> inline by calling an initializer of a non-generic type (very common) any 
> annotation is strictly redundant.
> 
> struct {
> let foo = Foo()
> }
> 
> Requiring a type annotation here feels very unnecessary and boilerplate-y.  I 
> adds no additional clarity to a reader of the code, only noise.  Noise 
> reduces clarity.  Small amounts of unnecessary or redundant information such 
> as in an individual stored property declaration are not that big a deal.  But 
> on balance they add up quickly and have an undesirable impact on the overall 
> clarity of code.
> 
> >
> > Daniel Duan
> > ___
> > 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 
> 
> 
> 
> 
> -- 
> Pranshu Goyal
> iOS Developer
> tlkn
> 
> ___
> 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] [Review] SE-0168: Multi-Line String Literals

[Daniel Duan via swift-evolution]

> On Apr 11, 2017, at 5:50 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Tue, Apr 11, 2017 at 7:32 PM, Brent Royal-Gordon via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> That’s also the example that kept me thinking for a while.
>> 
>> Overall the proposal is a great compromise to some issues I had with the 
>> first version. However I have a few more questions:
>> 
>> Why can’t we make it consistent and let the compiler add a new line after 
>> the starting delimiter.
>> 
>> let string = """↵
>> Swift↵
>> """
>> 
>> // result
>> ↵Swift↵
>> If one would would the behavior from the proposal it’s really easy to add a 
>> backslash after the starting delimiter.
>> 
>> 
>> let string = """\↵
>> Swift\↵
>> """
>> 
>> // result
>> Swift
>> This would be consistent and less confusing to learn.
>> 
> That would mean that code like this:
> 
>   print("""
>   A whole bunch of 
>   multiline text
>   """)
>   print("""
>   A whole bunch more 
>   multiline text
>   """)
> 
> Will print (with - to indicate blank lines):
> 
>   -
>   A whole bunch of
>   multiline text
>   -
>   -
>   A whole bunch more
>   multiline text
>   -
> 
> This is, to a first approximation, never what you actually want the computer 
> to do.
> 
> Brent, excellent job revising the proposal text. My question for you and the 
> other authors is the other way around: what is the rationale behind only 
> stripping the leading newline and not the trailing newline? While in many 
> cases a trailing newline is not harmful or even beneficial, if you trim the 
> one, wouldn't it make sense to trim the other? Wouldn't it make the rules 
> easier to explain to users too? For instance:
> 
> '''
> Hello, world!
> ‘''
For whatever reason, this reads like a new line is included to me. It maybe my 
Python experience. But another strange-ish idea came to me as I was thinking 
about it: this is what `print(“hello, world!”)` looks like in the repl. That’s 
kind of beautiful in my mind :)
> could instead be a one-line string "Hello, world!"
> 
> And those who need the trailing newline can trivially insist on it:
> 
> '''
> Hello, world!
> 
> '''
> 
> 
>> Can’t we make the indent algorithm work like this instead?
>> let string = """\↵
>> ↵
>> ··content text↵
>> """ // Indent starts with the first non space character
>> 
>> // result
>> 
>> ↵
>> ··content text↵
>> 
>> The line where the closing delimiter is trims all space chapters and the 
>> indent for the whole multi-line string is starting at the point where the 
>> first non-space chapters is in that line.
>> 
> 
> We could; I discuss that briefly in the very last section, on alternatives to 
> the indentation stripping we specify:
> 
>   • Stripping indentation to match the depth of the least indented line: 
> Instead of removing indentation to match the end delimiter, you remove 
> indentation to match the least indented line of the string itself. The issue 
> here is that, if all lines in a string should be indented, you can't use 
> indentation stripping. Ruby 2.3 does this with its heredocs, and Python's 
> dedent function also implements this behavior.
> 
> That doesn't quite capture the entire breadth of the problem with this 
> algorithm, though. What you'd like to do is say, "all of these lines are 
> indented four columns, so we should remove four columns of indentation from 
> each line". But you don't have columns; you have tabs and spaces, and they're 
> incomparable because the compiler can't know what tab stops you set. So we'd 
> end up calculating a common prefix of whitespace for all lines and removing 
> that. But that means, when someone mixes tabs and spaces accidentally, you 
> end up stripping an amount of indentation that is unrelated to anything 
> visible in your code. We could perhaps emit a warning in some suspicious 
> circumstances (like "every line has whitespace just past the end of 
> indentation, but some use tabs and others use spaces"), but if we do, we 
> can't know which one is supposed to be correct. With the proposed design, we 
> know what's correct—the last line—and any deviation from it can be flagged 
> *at the particular line which doesn't match our expectation*.
> 
> Even without the tabs and spaces issue, consider the case where you 
> accidentally don't indent a line far enough. With your algorithm, that's 
> indistinguishable from wanting the other lines to be indented more than that 
> one, so we generate a result you don't want and we don't (can't!) emit a 
> warning to point out the mistake. With the proposed algorithm, we can notice 
> there's an error and point to the line at fault.
> 
> Having the closing delimiter always be on its own line and using it to decide 
> how

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Ricardo Parada via swift-evolution]

If Xcode or code editors displayed a vertical line at the indentation boundary 
then it would be like having the continuation character without actually being 
there. The best of both worlds. That would be really nice. 



> On Apr 11, 2017, at 8:48 PM, Ricardo Parada via swift-evolution 
>  wrote:
> 
> 
> 
> 
>> On Apr 11, 2017, at 8:32 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> ...
>> But I'd love to see a faint reddish background behind tripled string literal 
>> content or a vertical line at the indentation boundary.
> 
> That would be very nice. :-)
> ___
> 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] ABI dashboard now up

[Ted Kremenek via swift-evolution]

Hi everyone,

We now have a dashboard up on Swift.org to track remaining tasks for ABI 
stability:

  https://swift.org/abi-stability/

The contents of the dashboard (which we may refine over time*) are largely 
drawn from JIRA and the ABI manifesto:

  https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md

The tasks currently tracked on the dashboard are fairly low-level details 
concerning the ABI itself.  These include details that should be re-reviewed 
and finalized, or finishing up areas we know are incomplete.

Ted

* - One area that is currently under represented in the dashboard is the work 
on the standard library.  The work needed to be done is fairly well understood; 
there's just some effort needed to aggregate that information into rows in the 
dashboard.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Xiaodi Wu via swift-evolution]

On Tue, Apr 11, 2017 at 7:50 PM, Xiaodi Wu  wrote:

> On Tue, Apr 11, 2017 at 7:32 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> That’s also the example that kept me thinking for a while.
>> --
>>
>> Overall the proposal is a great compromise to some issues I had with the
>> first version. However I have a few more questions:
>>
>>- Why can’t we make it consistent and let the compiler add a new line
>>after the starting delimiter.
>>
>> 
let string = """↵
>> Swift↵
>> """
>>
>> // result
>> ↵Swift↵
>>
>> If one would would the behavior from the proposal it’s really easy to add
>> a backslash after the starting delimiter.
>>
>> 
let string = """\↵
>> Swift\↵
>> """
>>
>> // result
>> Swift
>>
>> This would be consistent and less confusing to learn.
>>
>> That would mean that code like this:
>>
>> print("""
>> A whole bunch of
>> multiline text
>> """)
>> print("""
>> A whole bunch more
>> multiline text
>> """)
>>
>> Will print (with - to indicate blank lines):
>>
>> -
>> A whole bunch of
>> multiline text
>> -
>> -
>> A whole bunch more
>> multiline text
>> -
>>
>> This is, to a first approximation, never what you actually want the
>> computer to do.
>>
>
> Brent, excellent job revising the proposal text. My question for you and
> the other authors is the other way around: what is the rationale behind
> only stripping the leading newline and not the trailing newline? While in
> many cases a trailing newline is not harmful or even beneficial, if you
> trim the one, wouldn't it make sense to trim the other? Wouldn't it make
> the rules easier to explain to users too? For instance:
>
> '''
> Hello, world!
> '''
>
> could instead be a one-line string "Hello, world!"
>
> And those who need the trailing newline can trivially insist on it:
>
> '''
> Hello, world!
>
> '''
>

I should add, the motivation for proposing this revision to the rules is
that it would make it easy for a user to make use of the de-indenting
feature of the trailing ''' without opting into a trailing newline by
default.


>
>>- Can’t we make the indent algorithm work like this instead?
>>
>> let string = """\↵
>> ↵
>> ··content text↵
>> """ // Indent starts with the first non space character
>>
>> // result
>>
>> ↵
>> ··content text↵
>> 
>>
>> The line where the closing delimiter is trims all space chapters and the
>> indent for the whole multi-line string is starting at the point where the
>> first non-space chapters is in that line.
>>
>> We could; I discuss that briefly in the very last section, on
>> alternatives to the indentation stripping we specify:
>>
>> • Stripping indentation to match the depth of the least indented line:
>> Instead of removing indentation to match the end delimiter, you remove
>> indentation to match the least indented line of the string itself. The
>> issue here is that, if all lines in a string should be indented, you can't
>> use indentation stripping. Ruby 2.3 does this with its heredocs,
>> and Python's dedent function also implements this behavior.
>>
>> That doesn't quite capture the entire breadth of the problem with this
>> algorithm, though. What you'd like to do is say, "all of these lines are
>> indented four columns, so we should remove four columns of indentation from
>> each line". But you don't have columns; you have tabs and spaces, and
>> they're incomparable because the compiler can't know what tab stops you
>> set. So we'd end up calculating a common prefix of whitespace for all lines
>> and removing that. But that means, when someone mixes tabs and spaces
>> accidentally, you end up stripping an amount of indentation that is
>> unrelated to anything visible in your code. We could perhaps emit a warning
>> in some suspicious circumstances (like "every line has whitespace just past
>> the end of indentation, but some use tabs and others use spaces"), but if
>> we do, we can't know which one is supposed to be correct. With the proposed
>> design, we know what's correct—the last line—and any deviation from it can
>> be flagged *at the particular line which doesn't match our expectation*.
>>
>> Even without the tabs and spaces issue, consider the case where you
>> accidentally don't indent a line far enough. With your algorithm, that's
>> indistinguishable from wanting the other lines to be indented more than
>> that one, so we generate a result you don't want and we don't (can't!) emit
>> a warning to point out the mistake. With the proposed algorithm, we can
>> notice there's an error and point to the line at fault.
>>
>> Having the closing delimiter always be on its own line and using it to
>> decide how much whitespace to strip is better because it gives the compiler
>> a firm baseline to work from. That means it can tell you what's wrong and
>> where, instead of doing the dumb

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Xiaodi Wu via swift-evolution]

On Tue, Apr 11, 2017 at 7:32 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> That’s also the example that kept me thinking for a while.
> --
>
> Overall the proposal is a great compromise to some issues I had with the
> first version. However I have a few more questions:
>
>- Why can’t we make it consistent and let the compiler add a new line
>after the starting delimiter.
>
> 
let string = """↵
> Swift↵
> """
>
> // result
> ↵Swift↵
>
> If one would would the behavior from the proposal it’s really easy to add
> a backslash after the starting delimiter.
>
> 
let string = """\↵
> Swift\↵
> """
>
> // result
> Swift
>
> This would be consistent and less confusing to learn.
>
> That would mean that code like this:
>
> print("""
> A whole bunch of
> multiline text
> """)
> print("""
> A whole bunch more
> multiline text
> """)
>
> Will print (with - to indicate blank lines):
>
> -
> A whole bunch of
> multiline text
> -
> -
> A whole bunch more
> multiline text
> -
>
> This is, to a first approximation, never what you actually want the
> computer to do.
>

Brent, excellent job revising the proposal text. My question for you and
the other authors is the other way around: what is the rationale behind
only stripping the leading newline and not the trailing newline? While in
many cases a trailing newline is not harmful or even beneficial, if you
trim the one, wouldn't it make sense to trim the other? Wouldn't it make
the rules easier to explain to users too? For instance:

'''
Hello, world!
'''

could instead be a one-line string "Hello, world!"

And those who need the trailing newline can trivially insist on it:

'''
Hello, world!

'''



>- Can’t we make the indent algorithm work like this instead?
>
> let string = """\↵
> ↵
> ··content text↵
> """ // Indent starts with the first non space character
>
> // result
>
> ↵
> ··content text↵
> 
>
> The line where the closing delimiter is trims all space chapters and the
> indent for the whole multi-line string is starting at the point where the
> first non-space chapters is in that line.
>
> We could; I discuss that briefly in the very last section, on alternatives
> to the indentation stripping we specify:
>
> • Stripping indentation to match the depth of the least indented line:
> Instead of removing indentation to match the end delimiter, you remove
> indentation to match the least indented line of the string itself. The
> issue here is that, if all lines in a string should be indented, you can't
> use indentation stripping. Ruby 2.3 does this with its heredocs,
> and Python's dedent function also implements this behavior.
>
> That doesn't quite capture the entire breadth of the problem with this
> algorithm, though. What you'd like to do is say, "all of these lines are
> indented four columns, so we should remove four columns of indentation from
> each line". But you don't have columns; you have tabs and spaces, and
> they're incomparable because the compiler can't know what tab stops you
> set. So we'd end up calculating a common prefix of whitespace for all lines
> and removing that. But that means, when someone mixes tabs and spaces
> accidentally, you end up stripping an amount of indentation that is
> unrelated to anything visible in your code. We could perhaps emit a warning
> in some suspicious circumstances (like "every line has whitespace just past
> the end of indentation, but some use tabs and others use spaces"), but if
> we do, we can't know which one is supposed to be correct. With the proposed
> design, we know what's correct—the last line—and any deviation from it can
> be flagged *at the particular line which doesn't match our expectation*.
>
> Even without the tabs and spaces issue, consider the case where you
> accidentally don't indent a line far enough. With your algorithm, that's
> indistinguishable from wanting the other lines to be indented more than
> that one, so we generate a result you don't want and we don't (can't!) emit
> a warning to point out the mistake. With the proposed algorithm, we can
> notice there's an error and point to the line at fault.
>
> Having the closing delimiter always be on its own line and using it to
> decide how much whitespace to strip is better because it gives the compiler
> a firm baseline to work from. That means it can tell you what's wrong and
> where, instead of doing the dumb computer thing and computing a result
> that's technically correct but useless.
>
> PS: If we’d get this feature in Swift, it would be nice if Xcode and other
> IDEs which supports Swift could show space characters that are inside a
> string literal (not other space character <- which is already supported),
> so it would be easier to tell what’s part of the string and what is not.
>
> That would be very nice indeed. The pr

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Brent Royal-Gordon via swift-evolution]

> On Apr 11, 2017, at 4:52 PM, Ricardo Parada via swift-evolution 
>  wrote:
> 
> I think the enabling of the indentation stripping could be relaxed a little 
> bit and not require the opening delimiter to end its line.  So for example, 
> it would be possible to do this:
> 
> 
> let xml = """
>  
>  
>  \(author)
>  XML Developer's Guide
>  Computer
>  44.95
>  2000-10-01
>  An in-depth look at creating applications with 
> XML.
>  
>  
>  """


We could definitely do this, but I can't figure out a simple set of rules that 
would support both that and this:

let xml = """
 
 
 
 \(author)
 XML Developer's Guide
 Computer
 44.95
 2000-10-01
 An in-depth look at creating applications with 
XML.
 
 
 """

If we have to choose only one to support, I think the second syntax is the best 
choice, because it does a better job of letting you format the literal 
flexibly. Putting the first line of the literal on the same line as the 
expression only works if the expression is short, as in this example. If the 
expression is longer or more complicated, it starts to break down.

You could support both by saying that the leading newline is stripped if the 
first line is blank, but that makes the rules more complicated and 
unprincipled, not less. 

(On the other hand, I believe that adding a backslash at the end of the first 
line in my example would make it work with your algorithm. Hmm.)

> I think Brent did a super awesome job.  The proposal is very detailed with a 
> ton of examples. I think it covers just about everything that people have 
> asked for.  


Thanks! I really just swept in at the eleventh hour and wrote down what John 
was thinking, though. (The phrase "mind reading skills" was used.) I didn't 
work through these tradeoffs, hack several different designs into the compiler 
to see how they'd work, and pick an actual design.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Ricardo Parada via swift-evolution]

> On Apr 11, 2017, at 8:32 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> ...
> But I'd love to see a faint reddish background behind tripled string literal 
> content or a vertical line at the indentation boundary.

That would be very nice. :-)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Brent Royal-Gordon via swift-evolution]

> On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> That’s also the example that kept me thinking for a while.
> 
> Overall the proposal is a great compromise to some issues I had with the 
> first version. However I have a few more questions:
> 
> Why can’t we make it consistent and let the compiler add a new line after the 
> starting delimiter.
> 
> let string = """↵
> Swift↵
> """
> 
> // result
> ↵Swift↵
> If one would would the behavior from the proposal it’s really easy to add a 
> backslash after the starting delimiter.
> 
> 
> let string = """\↵
> Swift\↵
> """
> 
> // result
> Swift
> This would be consistent and less confusing to learn.
> 
That would mean that code like this:

print("""
A whole bunch of 
multiline text
""")
print("""
A whole bunch more 
multiline text
""")

Will print (with - to indicate blank lines):

-
A whole bunch of
multiline text
-
-
A whole bunch more
multiline text
-

This is, to a first approximation, never what you actually want the computer to 
do.
> Can’t we make the indent algorithm work like this instead?
> let string = """\↵
> ↵
> ··content text↵
> """ // Indent starts with the first non space character
> 
> // result
> 
> ↵
> ··content text↵
> 
> The line where the closing delimiter is trims all space chapters and the 
> indent for the whole multi-line string is starting at the point where the 
> first non-space chapters is in that line.
> 
We could; I discuss that briefly in the very last section, on alternatives to 
the indentation stripping we specify:

• Stripping indentation to match the depth of the least indented line: 
Instead of removing indentation to match the end delimiter, you remove 
indentation to match the least indented line of the string itself. The issue 
here is that, if all lines in a string should be indented, you can't use 
indentation stripping. Ruby 2.3 does this with its heredocs, and Python's 
dedent function also implements this behavior.

That doesn't quite capture the entire breadth of the problem with this 
algorithm, though. What you'd like to do is say, "all of these lines are 
indented four columns, so we should remove four columns of indentation from 
each line". But you don't have columns; you have tabs and spaces, and they're 
incomparable because the compiler can't know what tab stops you set. So we'd 
end up calculating a common prefix of whitespace for all lines and removing 
that. But that means, when someone mixes tabs and spaces accidentally, you end 
up stripping an amount of indentation that is unrelated to anything visible in 
your code. We could perhaps emit a warning in some suspicious circumstances 
(like "every line has whitespace just past the end of indentation, but some use 
tabs and others use spaces"), but if we do, we can't know which one is supposed 
to be correct. With the proposed design, we know what's correct—the last 
line—and any deviation from it can be flagged *at the particular line which 
doesn't match our expectation*.

Even without the tabs and spaces issue, consider the case where you 
accidentally don't indent a line far enough. With your algorithm, that's 
indistinguishable from wanting the other lines to be indented more than that 
one, so we generate a result you don't want and we don't (can't!) emit a 
warning to point out the mistake. With the proposed algorithm, we can notice 
there's an error and point to the line at fault.

Having the closing delimiter always be on its own line and using it to decide 
how much whitespace to strip is better because it gives the compiler a firm 
baseline to work from. That means it can tell you what's wrong and where, 
instead of doing the dumb computer thing and computing a result that's 
technically correct but useless.
> PS: If we’d get this feature in Swift, it would be nice if Xcode and other 
> IDEs which supports Swift could show space characters that are inside a 
> string literal (not other space character <- which is already supported), so 
> it would be easier to tell what’s part of the string and what is not.
> 
That would be very nice indeed. The prototype's tokenizer simply concatenates 
together and computes the string literal's contents after whitespace stripping, 
but in principle, I think it could probably preserve enough information to tell 
SourceKit where the indentation ends and the literal content begins. (The 
prototype is John's department, though, not mine.) Xcode would then have to do 
something with that information, though, and swift-evolution can't make the 
Xcode team do so. But I'd love to see a faint reddish background behind tripled 
string literal content or a vertical line at the indentation boundary.

In the meantime, this design *does* provide an unambiguous indicator of how 
mu

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Jakub Suder via swift-evolution]

I'm honestly having trouble believing that this is being seriously
proposed... I always saw type inference as one of the most important
advantages of Swift over some older languages, the Swift ebook mentions
many times how smart Swift is that it can infer types for you so that you
don't have to type too much boilerplate. And here we're talking about
removing this feature that was advertised from the beginning as Swift's
strong point, in order to make the compilation faster? The compiler speeds
will be improved, the syntax will stay with us.

Yes, specifying the type is often clearer, I do it myself, e.g. "var
enabled: Bool = true". But that's my choice, not something I should be
forced to do. It's something to put in style guides, not to enforce with
the compiler.


On 8 April 2017 at 07:40, Pranshu Goyal via swift-evolution <
swift-evolution@swift.org> wrote:

> I agree with the sentiment of the proposal, it does add value to overall
> efficiency of swift and make things simpler for the swift team, but as
> Matthew said a blanket ban will add noise to the code. Also this particular
> feature is one of those niceties about swift which makes it very welcoming
> to new adopters.
>
> If some middle ground can be proposed to this problem then I think we will
> be making a lot of people happy.
>
> On 7 April 2017 at 18:31, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > On Apr 7, 2017, at 2:21 AM, Daniel Duan via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > Hi all,
>> >
>> > In a discussion about inferring parameter types from default value,
>> Slava brought up some performance problems caused by type inference for
>> stored properties in side types:
>> >
>> > https://lists.swift.org/pipermail/swift-evolution/Week-of-
>> Mon-20170313/033882.html
>> >
>> > Towards the end, the post mentioned that some Swift team members
>> contemplated requiring types for stored properties in type declarations. I
>> think this idea deserves some more attention. Hence this last minute
>> idea-floating.
>> >
>> > In addition to solving a performance headache in implementation,
>> there're always the general benefit of making type declartion more explicit
>> and readable (clarity for reader should out-weigh pleasure of the author).
>> Making the
>> > language slightly more consistent (we are not inferring types for
>> default parameter values in function anyways).
>> >
>> > The cons for doing this are obvious too: the inference makes the
>> language feels more friendly and is, undoubtedly, a beloved feature for
>> many. This would be a source breaking change.
>> >
>> > Just thought I'd float the idea to gather some quick reaction. What do
>> y'all think?
>>
>> I’m willing to keep an open mind on this topic but I don’t think
>> wholesale banning of inference is the right thing to do.  Here is an
>> example of a case where I do not want to give up inference.  When a
>> property is initialized inline by calling an initializer of a non-generic
>> type (very common) any annotation is strictly redundant.
>>
>> struct {
>> let foo = Foo()
>> }
>>
>> Requiring a type annotation here feels very unnecessary and
>> boilerplate-y.  I adds no additional clarity to a reader of the code, only
>> noise.  Noise reduces clarity.  Small amounts of unnecessary or redundant
>> information such as in an individual stored property declaration are not
>> that big a deal.  But on balance they add up quickly and have an
>> undesirable impact on the overall clarity of code.
>>
>> >
>> > Daniel Duan
>> > ___
>> > 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
>>
>
>
>
> --
> *Pranshu Goyal*
> *iOS Developer*
> *tlkn*
>
> ___
> 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] [Review] SE-0168: Multi-Line String Literals

[Brent Royal-Gordon via swift-evolution]

> On Apr 11, 2017, at 7:33 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> 1. "Tripled string literals support backslash escapes and interpolation as 
> normal, except that you can also place a backslash immediately before a 
> newline. This indicates that the newline is merely for code formatting and 
> should not be present in the resulting string:"
> - I think this a confusion point which should not be in this proposal. 
> Currently in "normal" strings we just can't have single backlash as it will 
> generate "invalid escape sequence in literal" warning.
> Is this feature worth the added complexity? I'm not sure currently.


I should probably explain this feature a little better, but basically, it's 
there for two reasons:

1. It lets you suppress the trailing newline that this feature would otherwise 
add.

2. It lets you use multi-line string literals for strings which don't 
inherently have newlines in them, but which are long, so you want to hard-wrap 
them.

Let me explain that second one in more detail. Suppose we decide to reimplement 
Swift in Swift, and your job is to port the table of diagnostic messages. Some 
of these messages are pretty long. For example, here's one:

WARNING(is_expr_same_type,none,
"checking a value with optional type %0 against dynamic type %1 
"
"succeeds whenever the value is non-'nil'; did you mean to use "
"'!= nil'?", (Type, Type))

You decide to model the diagnostics as an enum:

extension Diagnostic {
enum Message {
...
case isExprSameType(from: AST.Type, to: AST.Type)
...
}
}

And now you want to write the actual error message. But this is a pretty long 
string. The project's coding standards requires that lines not get too wide, 
but you don't want actual newlines to be in the resulting string.

We think you should be able to write your code like this:

extension Diagnostic.Message: CustomStringConvertible {
var description: String {
switch self {
...
case .isExprSameType(let from, let to):
return """
checking a value with optional type 
\(from) against dynamic type \(to) \
succeeds whenever the value is 
non-'nil'; did you mean to use '!= nil'?\
"""
...
}
}

You are using the (hopefully familiar) multiline string syntax and its 
(hopefully familiar) indentation support; you're just backslashing the newlines 
to indicate you don't really want them.

Now, one alternative to support this use case is to make newlines 
non-significant by default—if you wanted a real newline, you'd need to 
backslash it (or perhaps use `\n`). But that's no good because (a) we think 
significant newlines are the more obvious semantic and will be more common, and 
(b) when you're using non-significant newlines, you really care about the 
whitespace before the newline anyway. In this example, there's a space before 
one of the two backslashes; the string would not render correctly without that 
space. The backslash at the end of the line makes that whitespace visible and 
protects it from overzealous tools (like Xcode with certain settings enabled) 
which like to trim trailing whitespace from lines.

So, I think escaped newlines are a small but important tool that makes this 
feature applicable to more use cases. And I don't think they'll confuse users.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Ricardo Parada via swift-evolution]

Sure. Let me quote the proposal:

"We propose that, when the opening delimiter ends its line and the closing 
delimiter starts its line, tripled string literals should automatically remove 
whatever indentation is present before the closing delimiter from each line 
above it, as well as removing the leading newline. "

let str = """My favorite things in life don't cost any money.↵
It's really clear that the most precious resource we all have is time. - 
Steve Jobs"""


If I understand correctly, in this example, the opening delimiter does not end 
its line and the closing delimiter does not begin its line.  Therefore, the 
indentation stripping is not enabled and would yield this:

My favorite things in life don't cost any money.↵
It's really clear that the most precious resource we all have is time. - 
Steve Jobs


I personally do not care if indentation stripping is always enabled.  But after 
having seen all kinds of responses I would not be surprised if someone will ask 
for the ability to turn indentation stripping on/off.   :-)

I think the enabling of the indentation stripping could be relaxed a little bit 
and not require the opening delimiter to end its line.  So for example, it 
would be possible to do this:


let xml = """
 
 
 \(author)
 XML Developer's Guide
 Computer
 44.95
 2000-10-01
 An in-depth look at creating applications with 
XML.
 
 
 """

Notice that here, the opening delimiter does not end its line but the closing 
delimiter does begin its line.  This could produce the following:




John Doe
XML Developer's Guide
Computer
44.95
2000-10-01
An in-depth look at creating applications with XML.




I think Brent did a super awesome job.  The proposal is very detailed with a 
ton of examples. I think it covers just about everything that people have asked 
for.  

Regards,
Ricardo



On Apr 11, 2017, at 1:06 PM, Adrian Zubarev mailto:adrian.zuba...@devandartist.com>> wrote:

> Can you elaborate a small example please, so I can better understand what you 
> asked for?
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 11. April 2017 um 18:51:45, Ricardo Parada (rpar...@mac.com 
> ) schrieb:
> 
>> 
>> 
>> Hi Adrian,
>> 
>> I think having the closing """ on a line by itself activates the indentation 
>> stripping feature. So if it was to change as you suggest then how would you 
>> turn off indentation stripping?
>> 
>> 
>> 
>> On Apr 11, 2017, at 11:08 AM, Adrian Zubarev via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> This would be consistent and less confusing to learn.
>>> 
>>> Can’t we make the indent algorithm work like this instead?
>>> let string = """\↵
>>> ↵
>>> ··content text↵
>>> """ // Indent starts with the first non space character
>>> 
>>> // result
>>> 
>>> ↵
>>> ··content text↵
>>> 
>>> The line where the closing delimiter is trims all space chapters and the 
>>> indent for the whole multi-line string is starting at the point where the 
>>> first non-space chapters is in that line.
>>> 
>>> What do you think?
>>> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

[Jakub Suder via swift-evolution]

Thanks for the explanation Adrian, I also had to Google this :)

Personally I'd love some kind of solution that would prevent this confusion
of why this method does different things when called on the same object in
two different ways, but I don't have any ideas how this could be solved...
It's something that most people learning Swift definitely won't expect to
work as it works now (unless they're coming from a language that mostly
works with static dispatch, but I'm guessing most people won't).


On 11 April 2017 at 15:50, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> I myself pitched that requirement quite a few times on the list. Thank
> you, finally I understood why it’s not possible. Now I fully agree that the
> requirement of an override should not exist for the base type conforming to
> the protocol.
>
> For those who might misunderstand the concept of retroactive conformances
> just like I did it, here is a quick snippet for you.
>
> Imagine you’re working on some iOS project and for some reason you need an
> existential that only knows a property title of type String?.
>
> protocol P { var title: String? { get set } }
>
> Now you could retroactively conform types that already have this property
> to that protocol P without the need of implementing the property
> yourself. Think of it as a backdoor. ;)
>
> extension UIViewController : P {} // This just works
>
> The proposed solution will simply break this nice feature.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 11. April 2017 um 00:52:01, Xiaodi Wu via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> Requiring `override` breaks retroactive conformance of types to protocols.
> This idea has been brought up over half a dozen times. Each time it fails
> in not being able to accommodate retroactive conformance.
>
>
> ___
> 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] switch must be exhaustive, consider adding a default clause

[Robert Widmann via swift-evolution]

What Joe is referring to is the kind of refinement-style rules that would be 
necessary to teach the type checker about how to that kind of analysis.  Right 
now, all our switch analysis, and even this example, are just DI and 
control-flow checks.

> On Apr 11, 2017, at 2:24 PM, Drew Crawford via swift-evolution 
>  wrote:
> 
> 
> 
> 
> On April 11, 2017 at 11:38:05 AM, Joe Groff (jgr...@apple.com 
> ) wrote:
> 
>> By design, Swift avoids making semantic rules based on that kind of 
>> analysis, since it would be brittle and difficult to describe when the 
>> compiler can and can't see that a condition holds nonlocally like this.
> 
> Swift *currently implements* semantic rules based on this kind of analysis.  
> Exhibit A:
> 
> func foo() {
> 
> let a: Bool
> 
> if UUID().uuidString == "non-local condition" {
> 
> a = true
> 
> }
> 
> else {
> 
> preconditionFailure("Don't initialize a")
> 
> }
> 
> print("\(a)") //NOT: error: a is uninitialized
> 
> }
> 
> ___
> 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] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Vladimir.S via swift-evolution]

On 11.04.2017 19:47, Jose Cheyo Jimenez via swift-evolution wrote:


On Apr 6, 2017, at 4:25 PM, Slava Pestov via swift-evolution 
mailto:swift-evolution@swift.org>> wrote:


Strong -1. This is a source breaking change, but Swift 4 stage 2 is already 
over.


I agree with you here. I don't think the proposal will be accepted as is, because of 
the breaking change.


What if there was a way to make this a new feature so it is not a breaking 
change?

I can see this same proposal being accepted if it was revised to mark the new 
extension behavior explicitly.


I like this idea, only extensions explicitly marked as "privileged" can have access 
to private members of the type.
But I suggest then go forward and do not use extension to access the private members 
but instead introduce new construction, which also can have stored properties and 
will have access modifier rules for types (not the rules for extensions). And such 
construction will be treated as continued declaration of the type itself. Only in the 
same file for now.


For example (just as idea for discussion) :

struct A {
  private var x = 0
}

continue A: P1 {
  private var y = 10
  func foo() {print(x + y)}
}

continue A: P2 {
  func bar() {print(x + y)}
}

Probably such type also should be marked somehow to be allowed to have continued 
definition, like


struct A split {
}

Later, when we'll have submodules, such 'continue' construction for the type should 
be allowed in other files of the same submodule and provide the flexible way to 
define the same type in a number of files.




*Type.swift*
*
*
struct A {
private func foo() {}
}

*partial* extension A {  // any other keyword would do here or even \
func baz() {
foo()  // okay
}
}

extension A {
func boo() {
foo()  // error. Same as swift 3.
}
}

*Other.swift*
*
*
*partial* extension A {  // error. Partial extensions only allowed within the 
declaring file.

}

extension A {
func boo() {
foo()  // error. Same as swift 3.
}
}





Slava

On Apr 6, 2017, at 4:10 PM, Douglas Gregor > wrote:


Hello Swift community,

The review of SE-0169 "Improve Interaction Between private Declarations and 
Extensions" begins now and runs through April 11, 2017. The proposal is available 
here:



https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

Reviews are an important part of the Swift evolution process. All reviews should 
be sent to the swift-evolution mailing list at


https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:


Proposal link:


https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

Reply text

Other replies


  
What
  goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your review:


  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to 
Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do
you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or 
an
in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Doug

Review Manager

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


___
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] [Review] SE-0168: Multi-Line String Literals

[Brent Royal-Gordon via swift-evolution]

> On Apr 11, 2017, at 7:33 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> 2. Seems like a mistake:
> "Multi-line string with indentation stripping prevented by whitespace before 
> leading newline"
> 
> """↵
> Hello↵
> world!"""
> 
> Creates a string with:
> 
> ↵
> Hello↵
> world!
> 
> I believe it should be just:
> 
> Hello↵
> world!


Sorry, this example is mislabeled. (The same heading is used twice.) It should 
be something like "Multi-line string with indentation stripping prevented by 
non-whitespace before trailing delimiter".

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Xiaodi Wu via swift-evolution]

Great, thanks for the clarification.
On Tue, Apr 11, 2017 at 14:50 John McCall  wrote:

> On Apr 11, 2017, at 3:37 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> SE-0169 is under active review, and is about expanding the meaning of
> scope to include extensions in the same file. The last day of the review
> period is today.
>
> What is this about yet another change?
>
>
> SE-0169 appears to say that extensions in the same file should not have
> access to each other's members if they are not in the same file as the type
> declaration.  Some reviewers have specifically objected to that clause as
> counter to the overall design of SE-0169.  Most reviewers appear to have
> overlooked it.  I have not seen any specific support for that clause that
> was not tied to overall disapproval of SE-0169.
>
> The Core Team often changes minor things like this by fiat after review;
> swift-evolution is not a legislative process where every last detail needs
> formal approval.  We'll have to talk about it if we decide to accept
> SE-0169.
>
> John.
>
> On Tue, Apr 11, 2017 at 14:31 David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> We’re not talking about the same proposal. I’m talking about SE-0169
>
> On 11 Apr 2017, at 19:49, Daniel Duan  wrote:
>
> This never went into a review. The pull request is still open
> https://github.com/apple/swift-evolution/pull/587
>
> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I don't want to make any change until Chris has been able to chime in. If
> he agrees with us, what should be done?
>
> • Immediate change in the proposal?
> • Would it have to go through a new review?
> • Or can the Core Team make the change if it is accepted?
>
> On 11 Apr 2017, at 19:01, John McCall  wrote:
>
>
> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On 11 Apr 2017, at 16:27, Matthew Johnson  wrote:
>
>
>
> Sent from my iPad
>
> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 11 Apr 2017, at 13:29, Jonathan Hull  wrote:
>
>
> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On 11 Apr 2017, at 09:40, John McCall  wrote:
>
> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Sent from my iPhone
> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I have not voted in favor or against the proposal. I have been reading a
> lot of responses but I agree with Tony.
>
> When I started reading the proposal everything was more or less fine half
> way through the proposal because it was reverting private to fileprivate
> between the type and its extensions within the same file. I said, if you
> think of the type and its extensions as a unit then it makes sense. I can
> explain that.
>
> Then it started describing a different behavior among the extensions
> located in a file separate from the file containing the definition of the
> type. That just started a whole debate inside my head and I understand the
> passionate responses on both sides.
>
> But then I imagined myself explaining this to someone new to Swift and it
> just doesn't seem right. If it becomes convoluted then that's a red flag
> that it does not belong in Swift.
>
>
> I understand what you are saying and I wouldn't be against relaxing that
> requirement (not talking for Chris here).
>
> The model would change from "Types share scopes with their extensions in
> the same file the type was defined" to "Types and their extensions share
> the same scope in each file".
>
>
> Oh, I had missed that somehow.  I agree that that is a very strange rule.
> Do you know why it was proposed that way?
>
>
> We had to take a stance and Chris seemed to prefer the rule that was
> proposed. I didn't press because I'm sure he has reasons for preferring it
> that way. But I have a preference for generalizing visibility to all
> extensions, even to those in a different file than the type.
>
>
> I think there is a technical limitation if the visibility goes beyond the
> compilation unit (unless whole module optimization is turned on).
>
>
> I’m not suggesting visibility beyond the compilation unit. That would
> break the hierarchy of visibility layers: accessibility levels have always
> been contained in one-another and that’s why you can go from *private*, to
>  *fileprivate*, to *internal*, to *public*, to *open* (but not the other
> way round) without the risk of any compilation error. If all scopes of a
> type were visible to each other (whatever the file), you could not go from
>  *private* to *fileprivate*.
>
> I’m talking about extensions of the same type in the same file (but in a
> separate file from the type) to be able to share private members:
>
> *Type.swift*
>
> struct A {
> }
>
> *Othe

Re: [swift-evolution] Enhancing access levels without breaking changes

[John McCall via swift-evolution]

> On Apr 11, 2017, at 3:37 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> SE-0169 is under active review, and is about expanding the meaning of scope 
> to include extensions in the same file. The last day of the review period is 
> today.
> 
> What is this about yet another change?

SE-0169 appears to say that extensions in the same file should not have access 
to each other's members if they are not in the same file as the type 
declaration.  Some reviewers have specifically objected to that clause as 
counter to the overall design of SE-0169.  Most reviewers appear to have 
overlooked it.  I have not seen any specific support for that clause that was 
not tied to overall disapproval of SE-0169.

The Core Team often changes minor things like this by fiat after review; 
swift-evolution is not a legislative process where every last detail needs 
formal approval.  We'll have to talk about it if we decide to accept SE-0169.

John.

> On Tue, Apr 11, 2017 at 14:31 David Hart via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> We’re not talking about the same proposal. I’m talking about SE-0169
> 
>> On 11 Apr 2017, at 19:49, Daniel Duan > > wrote:
>> 
>> This never went into a review. The pull request is still open 
>> https://github.com/apple/swift-evolution/pull/587 
>> 
>>> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I don't want to make any change until Chris has been able to chime in. If 
>>> he agrees with us, what should be done?
>>> 
>>> • Immediate change in the proposal?
>>> • Would it have to go through a new review?
>>> • Or can the Core Team make the change if it is accepted?
>>> 
>>> On 11 Apr 2017, at 19:01, John McCall >> > wrote:
>>> 
 
> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> 
> 
> On 11 Apr 2017, at 16:27, Matthew Johnson  > wrote:
> 
>> 
>> 
>> Sent from my iPad
>> 
>> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
 On 11 Apr 2017, at 13:29, Jonathan Hull >>> > wrote:
 
> 
> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> On 11 Apr 2017, at 09:40, John McCall  > wrote:
> 
>>> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>>> mailto:swift-evolution@swift.org>> 
>>> wrote:
>>> 
>>> Sent from my iPhone
>>> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>>> mailto:swift-evolution@swift.org>> 
>>> wrote:
>>> 
 I have not voted in favor or against the proposal. I have been 
 reading a lot of responses but I agree with Tony. 
 
 When I started reading the proposal everything was more or less 
 fine half way through the proposal because it was reverting 
 private to fileprivate between the type and its extensions within 
 the same file. I said, if you think of the type and its extensions 
 as a unit then it makes sense. I can explain that. 
 
 Then it started describing a different behavior among the 
 extensions located in a file separate from the file containing the 
 definition of the type. That just started a whole debate inside my 
 head and I understand the passionate responses on both sides. 
 
 But then I imagined myself explaining this to someone new to Swift 
 and it just doesn't seem right. If it becomes convoluted then 
 that's a red flag that it does not belong in Swift. 
>>> 
>>> I understand what you are saying and I wouldn't be against relaxing 
>>> that requirement (not talking for Chris here).
>>> 
>>> The model would change from "Types share scopes with their 
>>> extensions in the same file the type was defined" to "Types and 
>>> their extensions share the same scope in each file".
>> 
>> Oh, I had missed that somehow.  I agree that that is a very strange 
>> rule.  Do you know why it was proposed that way?
> 
> We had to take a stance and Chris seemed to prefer the rule that was 
> proposed. I didn't press because I'm sure he has reasons for 
> preferring it that way. But I have a preference for generalizing 
> visibility to all extensions, even to those in a different file than 
> the type.
 
 I think there is a technical limita

Re: [swift-evolution] Enhancing access levels without breaking changes

[Xiaodi Wu via swift-evolution]

SE-0169 is under active review, and is about expanding the meaning of scope
to include extensions in the same file. The last day of the review period
is today.

What is this about yet another change?
On Tue, Apr 11, 2017 at 14:31 David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> We’re not talking about the same proposal. I’m talking about SE-0169
>
> On 11 Apr 2017, at 19:49, Daniel Duan  wrote:
>
> This never went into a review. The pull request is still open
> https://github.com/apple/swift-evolution/pull/587
>
> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I don't want to make any change until Chris has been able to chime in. If
> he agrees with us, what should be done?
>
> • Immediate change in the proposal?
> • Would it have to go through a new review?
> • Or can the Core Team make the change if it is accepted?
>
> On 11 Apr 2017, at 19:01, John McCall  wrote:
>
>
> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On 11 Apr 2017, at 16:27, Matthew Johnson  wrote:
>
>
>
> Sent from my iPad
>
> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 11 Apr 2017, at 13:29, Jonathan Hull  wrote:
>
>
> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On 11 Apr 2017, at 09:40, John McCall  wrote:
>
> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Sent from my iPhone
> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I have not voted in favor or against the proposal. I have been reading a
> lot of responses but I agree with Tony.
>
> When I started reading the proposal everything was more or less fine half
> way through the proposal because it was reverting private to fileprivate
> between the type and its extensions within the same file. I said, if you
> think of the type and its extensions as a unit then it makes sense. I can
> explain that.
>
> Then it started describing a different behavior among the extensions
> located in a file separate from the file containing the definition of the
> type. That just started a whole debate inside my head and I understand the
> passionate responses on both sides.
>
> But then I imagined myself explaining this to someone new to Swift and it
> just doesn't seem right. If it becomes convoluted then that's a red flag
> that it does not belong in Swift.
>
>
> I understand what you are saying and I wouldn't be against relaxing that
> requirement (not talking for Chris here).
>
> The model would change from "Types share scopes with their extensions in
> the same file the type was defined" to "Types and their extensions share
> the same scope in each file".
>
>
> Oh, I had missed that somehow.  I agree that that is a very strange rule.
> Do you know why it was proposed that way?
>
>
> We had to take a stance and Chris seemed to prefer the rule that was
> proposed. I didn't press because I'm sure he has reasons for preferring it
> that way. But I have a preference for generalizing visibility to all
> extensions, even to those in a different file than the type.
>
>
> I think there is a technical limitation if the visibility goes beyond the
> compilation unit (unless whole module optimization is turned on).
>
>
> I’m not suggesting visibility beyond the compilation unit. That would
> break the hierarchy of visibility layers: accessibility levels have always
> been contained in one-another and that’s why you can go from *private*, to
>  *fileprivate*, to *internal*, to *public*, to *open* (but not the other
> way round) without the risk of any compilation error. If all scopes of a
> type were visible to each other (whatever the file), you could not go from
>  *private* to *fileprivate*.
>
> I’m talking about extensions of the same type in the same file (but in a
> separate file from the type) to be able to share private members:
>
> *Type.swift*
>
> struct A {
> }
>
> *Other.swift*
>
> extension A {
> func foo() {
> bar()
> }
> }
>
> extension A {
> private func bar() {
> }
> }
>
>
> If this is not how your proposal already works I missed that aspect
> earlier and find it extremely perplexing (which is probably why I missed
> it).
>
>
> It's mentioned in the Derailed design section:
>
> *This proposal does not change the behavior of extensions that are not in
> the same file as the type - i.e., extensions in a seperate file to the type
> do not share access between themselves:*
>
> But I agree this should be changed if there is no major technical reason
> against it.
>
>
> I'm not aware of any technical reason why extensions in the same file
> should not have access to each other's members.
>
> John.
>
>
> It leaves scoped access working as in Swift 3 in exactly the case where it
> is least useful.  We cannot place

Re: [swift-evolution] Enhancing access levels without breaking changes

[David Hart via swift-evolution]

We’re not talking about the same proposal. I’m talking about SE-0169

> On 11 Apr 2017, at 19:49, Daniel Duan  wrote:
> 
> This never went into a review. The pull request is still open 
> https://github.com/apple/swift-evolution/pull/587 
> 
>> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I don't want to make any change until Chris has been able to chime in. If he 
>> agrees with us, what should be done?
>> 
>> • Immediate change in the proposal?
>> • Would it have to go through a new review?
>> • Or can the Core Team make the change if it is accepted?
>> 
>> On 11 Apr 2017, at 19:01, John McCall > > wrote:
>> 
>>> 
 On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 
 
 On 11 Apr 2017, at 16:27, Matthew Johnson >>> > wrote:
 
> 
> 
> Sent from my iPad
> 
> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>>> On 11 Apr 2017, at 13:29, Jonathan Hull >> > wrote:
>>> 
 
 On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 On 11 Apr 2017, at 09:40, John McCall >>> > wrote:
 
>> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Sent from my iPhone
>> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> I have not voted in favor or against the proposal. I have been 
>>> reading a lot of responses but I agree with Tony. 
>>> 
>>> When I started reading the proposal everything was more or less 
>>> fine half way through the proposal because it was reverting private 
>>> to fileprivate between the type and its extensions within the same 
>>> file. I said, if you think of the type and its extensions as a unit 
>>> then it makes sense. I can explain that. 
>>> 
>>> Then it started describing a different behavior among the 
>>> extensions located in a file separate from the file containing the 
>>> definition of the type. That just started a whole debate inside my 
>>> head and I understand the passionate responses on both sides. 
>>> 
>>> But then I imagined myself explaining this to someone new to Swift 
>>> and it just doesn't seem right. If it becomes convoluted then 
>>> that's a red flag that it does not belong in Swift. 
>> 
>> I understand what you are saying and I wouldn't be against relaxing 
>> that requirement (not talking for Chris here).
>> 
>> The model would change from "Types share scopes with their 
>> extensions in the same file the type was defined" to "Types and 
>> their extensions share the same scope in each file".
> 
> Oh, I had missed that somehow.  I agree that that is a very strange 
> rule.  Do you know why it was proposed that way?
 
 We had to take a stance and Chris seemed to prefer the rule that was 
 proposed. I didn't press because I'm sure he has reasons for 
 preferring it that way. But I have a preference for generalizing 
 visibility to all extensions, even to those in a different file than 
 the type.
>>> 
>>> I think there is a technical limitation if the visibility goes beyond 
>>> the compilation unit (unless whole module optimization is turned on).
>> 
>> I’m not suggesting visibility beyond the compilation unit. That would 
>> break the hierarchy of visibility layers: accessibility levels have 
>> always been contained in one-another and that’s why you can go from 
>> private, to fileprivate, to internal, to public, to open (but not the 
>> other way round) without the risk of any compilation error. If all 
>> scopes of a type were visible to each other (whatever the file), you 
>> could not go from private to fileprivate.
>> 
>> I’m talking about extensions of the same type in the same file (but in a 
>> separate file from the type) to be able to share private members:
>> 
>> Type.swift
>> 
>> struct A {
>> }
>> 
>> Other.swift
>> 
>> extension A {
>> func foo() {
>> bar()
>> }
>> }
>> 
>> extension A {
>> private func bar() {
>> }
>> }
>> 
> 
> If this is not how your proposal already works I missed that aspect 
> earlier and find it extremely perplexing

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Tino Heth via swift-evolution]

>> — It adds no power to the language
>> The proposal solves no real problem, but rather encourages a certain style 
>> of programming, which is quite popular among authors of styleguides, but has 
>> no clear net gain.
> 
> While your other points are defendable, I have to disagree here. It does 
> bring value to a population of developers (me included) for whom that style 
> of programming adds a lot of readability. It's part of style guides for a 
> reason.
… and it worked well enough, even with only three access levels. Is it really 
that beneficial to have properties that are only visible to certain extensions 
in a given file?
If I had a type that
a) implements some protocols (or has some other motivation to be split)
b) has members that should be hidden, but exposed to a single other type 
(fileprivate would be just fine without this premise)
c) has no other members that should be shared with a different alien type (that 
would force us to expose those parts to a type that should have no access)
d) has elements that are so fragile that they should be protected from any 
other type (SE-0169)
e) at the same time, it has to be fine that those fragile members of a 
nontrivial type can be accessed from all of its extensions that are located in 
the same file

SE-0169 would be the perfect answer to such a scenario, but I don't think I 
will encounter such types often:
As soon as one requirement isn't fulfilled, the whole purpose of those 
complicated modifiers is defeated, because our type leaks data that should be 
contained securely.
The construct of fileprivate and private with different meanings offers no 
fundamental benefit over internal — it just delays the issues it wants to solve 
a tiny bit.

>> — It diminishes the need for fileprivate without making it redundant
>> It would be nice to get rid of an access level, but having four common ones 
>> and fileprivate as an exotic outlier doesn't feel right for me.
> 
> Doesn't the argument of progressive disclosure sway you here? open is already 
> an outlier that only library authors will play with, and that's a good thing. 
> It reduces the number of access level truly useful on a day to day basis, 
> while leaving the others for more narrow purposes.
I would definitely prefer a set of easy to understand access levels over 
splitting modifiers in two groups, with one set reserved for "experts".
Access levels are a very basic concept, and imho they shouldn't need long 
explanations.

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

Re: [swift-evolution] switch must be exhaustive, consider adding a default clause

[Drew Crawford via swift-evolution]

On April 11, 2017 at 11:38:05 AM, Joe Groff (jgr...@apple.com) wrote:

By design, Swift avoids making semantic rules based on that kind of analysis, 
since it would be brittle and difficult to describe when the compiler can and 
can't see that a condition holds nonlocally like this.
Swift *currently implements* semantic rules based on this kind of analysis.  
Exhibit A:

func foo() {

    let a: Bool

    if UUID().uuidString == "non-local condition" {

        a = true

    }

    else {

        preconditionFailure("Don't initialize a")

    }

    print("\(a)") //NOT: error: a is uninitialized

}

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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution 
>  wrote:
> 
> I don't want to make any change until Chris has been able to chime in. If he 
> agrees with us, what should be done?
> 
> • Immediate change in the proposal?
> • Would it have to go through a new review?
This is major change. I would hope for a new review if the proposal is being 
accepted. 

I would also want this new behavior to be explicit thus making it a non 
breaking change. 
 
> • Or can the Core Team make the change if it is accepted?
> 
>> On 11 Apr 2017, at 19:01, John McCall  wrote:
>> 
>> 
>>> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On 11 Apr 2017, at 16:27, Matthew Johnson  wrote:
>>> 
 
 
 Sent from my iPad
 
> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
>>> On 11 Apr 2017, at 13:29, Jonathan Hull  wrote:
>>> 
>>> 
>>> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> On 11 Apr 2017, at 09:40, John McCall  wrote:
>>> 
> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>  wrote:
> 
> Sent from my iPhone
> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>  wrote:
> 
>> I have not voted in favor or against the proposal. I have been 
>> reading a lot of responses but I agree with Tony. 
>> 
>> When I started reading the proposal everything was more or less fine 
>> half way through the proposal because it was reverting private to 
>> fileprivate between the type and its extensions within the same 
>> file. I said, if you think of the type and its extensions as a unit 
>> then it makes sense. I can explain that. 
>> 
>> Then it started describing a different behavior among the extensions 
>> located in a file separate from the file containing the definition 
>> of the type. That just started a whole debate inside my head and I 
>> understand the passionate responses on both sides. 
>> 
>> But then I imagined myself explaining this to someone new to Swift 
>> and it just doesn't seem right. If it becomes convoluted then that's 
>> a red flag that it does not belong in Swift. 
> 
> I understand what you are saying and I wouldn't be against relaxing 
> that requirement (not talking for Chris here).
> 
> The model would change from "Types share scopes with their extensions 
> in the same file the type was defined" to "Types and their extensions 
> share the same scope in each file".
 
 Oh, I had missed that somehow.  I agree that that is a very strange 
 rule.  Do you know why it was proposed that way?
>>> 
>>> We had to take a stance and Chris seemed to prefer the rule that was 
>>> proposed. I didn't press because I'm sure he has reasons for preferring 
>>> it that way. But I have a preference for generalizing visibility to all 
>>> extensions, even to those in a different file than the type.
>> 
>> I think there is a technical limitation if the visibility goes beyond 
>> the compilation unit (unless whole module optimization is turned on).
> 
> I’m not suggesting visibility beyond the compilation unit. That would 
> break the hierarchy of visibility layers: accessibility levels have 
> always been contained in one-another and that’s why you can go from 
> private, to fileprivate, to internal, to public, to open (but not the 
> other way round) without the risk of any compilation error. If all scopes 
> of a type were visible to each other (whatever the file), you could not 
> go from private to fileprivate.
> 
> I’m talking about extensions of the same type in the same file (but in a 
> separate file from the type) to be able to share private members:
> 
> Type.swift
> 
> struct A {
> }
> 
> Other.swift
> 
> extension A {
> func foo() {
> bar()
> }
> }
> 
> extension A {
> private func bar() {
> }
> }
> 
 
 If this is not how your proposal already works I missed that aspect 
 earlier and find it extremely perplexing (which is probably why I missed 
 it).
>>> 
>>> It's mentioned in the Derailed design section:
>>> 
>>> This proposal does not change the behavior of extensions that are not in 
>>> the same file as the type - i.e., extensions in a seperate file to the type 
>>> do not share access between themselves:
>>> 
>>> But I agree this should be changed if there is no major technical reason 
>>> against it.
>> 
>> I'm not aware of any technical reason why extensions in the same file should 
>> not have access to each other's members.
>> 
>> John.
>> 
>>> 
>

Re: [swift-evolution] Enhancing access levels without breaking changes

[Daniel Duan via swift-evolution]

This never went into a review. The pull request is still open 
https://github.com/apple/swift-evolution/pull/587
> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution 
>  wrote:
> 
> I don't want to make any change until Chris has been able to chime in. If he 
> agrees with us, what should be done?
> 
> • Immediate change in the proposal?
> • Would it have to go through a new review?
> • Or can the Core Team make the change if it is accepted?
> 
> On 11 Apr 2017, at 19:01, John McCall  > wrote:
> 
>> 
>>> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
>>> 
>>> On 11 Apr 2017, at 16:27, Matthew Johnson >> > wrote:
>>> 
 
 
 Sent from my iPad
 
 On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
> 
>> On 11 Apr 2017, at 13:29, Jonathan Hull > > wrote:
>> 
>>> 
>>> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> On 11 Apr 2017, at 09:40, John McCall >> > wrote:
>>> 
> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> Sent from my iPhone
> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> I have not voted in favor or against the proposal. I have been 
>> reading a lot of responses but I agree with Tony. 
>> 
>> When I started reading the proposal everything was more or less fine 
>> half way through the proposal because it was reverting private to 
>> fileprivate between the type and its extensions within the same 
>> file. I said, if you think of the type and its extensions as a unit 
>> then it makes sense. I can explain that. 
>> 
>> Then it started describing a different behavior among the extensions 
>> located in a file separate from the file containing the definition 
>> of the type. That just started a whole debate inside my head and I 
>> understand the passionate responses on both sides. 
>> 
>> But then I imagined myself explaining this to someone new to Swift 
>> and it just doesn't seem right. If it becomes convoluted then that's 
>> a red flag that it does not belong in Swift. 
> 
> I understand what you are saying and I wouldn't be against relaxing 
> that requirement (not talking for Chris here).
> 
> The model would change from "Types share scopes with their extensions 
> in the same file the type was defined" to "Types and their extensions 
> share the same scope in each file".
 
 Oh, I had missed that somehow.  I agree that that is a very strange 
 rule.  Do you know why it was proposed that way?
>>> 
>>> We had to take a stance and Chris seemed to prefer the rule that was 
>>> proposed. I didn't press because I'm sure he has reasons for preferring 
>>> it that way. But I have a preference for generalizing visibility to all 
>>> extensions, even to those in a different file than the type.
>> 
>> I think there is a technical limitation if the visibility goes beyond 
>> the compilation unit (unless whole module optimization is turned on).
> 
> I’m not suggesting visibility beyond the compilation unit. That would 
> break the hierarchy of visibility layers: accessibility levels have 
> always been contained in one-another and that’s why you can go from 
> private, to fileprivate, to internal, to public, to open (but not the 
> other way round) without the risk of any compilation error. If all scopes 
> of a type were visible to each other (whatever the file), you could not 
> go from private to fileprivate.
> 
> I’m talking about extensions of the same type in the same file (but in a 
> separate file from the type) to be able to share private members:
> 
> Type.swift
> 
> struct A {
> }
> 
> Other.swift
> 
> extension A {
> func foo() {
> bar()
> }
> }
> 
> extension A {
> private func bar() {
> }
> }
> 
 
 If this is not how your proposal already works I missed that aspect 
 earlier and find it extremely perplexing (which is probably why I missed 
 it).
>>> 
>>> It's mentioned in the Derailed design section:
>>> 
>>> This proposal does not change the behavior of extensions that are not in 
>>> the same file as the type - i.e., extensions in a seperate file to the type 
>>> do not share access between themselves:
>>> 
>>> But I agree this shoul

Re: [swift-evolution] Enhancing access levels without breaking changes

[David Hart via swift-evolution]

I don't want to make any change until Chris has been able to chime in. If he 
agrees with us, what should be done?

• Immediate change in the proposal?
• Would it have to go through a new review?
• Or can the Core Team make the change if it is accepted?

> On 11 Apr 2017, at 19:01, John McCall  wrote:
> 
> 
>> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> On 11 Apr 2017, at 16:27, Matthew Johnson  wrote:
>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
 On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
  wrote:
 
 
>> On 11 Apr 2017, at 13:29, Jonathan Hull  wrote:
>> 
>> 
>> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
>>  wrote:
>> 
>> On 11 Apr 2017, at 09:40, John McCall  wrote:
>> 
 On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
  wrote:
 
 Sent from my iPhone
 On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
  wrote:
 
> I have not voted in favor or against the proposal. I have been 
> reading a lot of responses but I agree with Tony. 
> 
> When I started reading the proposal everything was more or less fine 
> half way through the proposal because it was reverting private to 
> fileprivate between the type and its extensions within the same file. 
> I said, if you think of the type and its extensions as a unit then it 
> makes sense. I can explain that. 
> 
> Then it started describing a different behavior among the extensions 
> located in a file separate from the file containing the definition of 
> the type. That just started a whole debate inside my head and I 
> understand the passionate responses on both sides. 
> 
> But then I imagined myself explaining this to someone new to Swift 
> and it just doesn't seem right. If it becomes convoluted then that's 
> a red flag that it does not belong in Swift. 
 
 I understand what you are saying and I wouldn't be against relaxing 
 that requirement (not talking for Chris here).
 
 The model would change from "Types share scopes with their extensions 
 in the same file the type was defined" to "Types and their extensions 
 share the same scope in each file".
>>> 
>>> Oh, I had missed that somehow.  I agree that that is a very strange 
>>> rule.  Do you know why it was proposed that way?
>> 
>> We had to take a stance and Chris seemed to prefer the rule that was 
>> proposed. I didn't press because I'm sure he has reasons for preferring 
>> it that way. But I have a preference for generalizing visibility to all 
>> extensions, even to those in a different file than the type.
> 
> I think there is a technical limitation if the visibility goes beyond the 
> compilation unit (unless whole module optimization is turned on).
 
 I’m not suggesting visibility beyond the compilation unit. That would 
 break the hierarchy of visibility layers: accessibility levels have always 
 been contained in one-another and that’s why you can go from private, to 
 fileprivate, to internal, to public, to open (but not the other way round) 
 without the risk of any compilation error. If all scopes of a type were 
 visible to each other (whatever the file), you could not go from private 
 to fileprivate.
 
 I’m talking about extensions of the same type in the same file (but in a 
 separate file from the type) to be able to share private members:
 
 Type.swift
 
 struct A {
 }
 
 Other.swift
 
 extension A {
 func foo() {
 bar()
 }
 }
 
 extension A {
 private func bar() {
 }
 }
 
>>> 
>>> If this is not how your proposal already works I missed that aspect earlier 
>>> and find it extremely perplexing (which is probably why I missed it).
>> 
>> It's mentioned in the Derailed design section:
>> 
>> This proposal does not change the behavior of extensions that are not in the 
>> same file as the type - i.e., extensions in a seperate file to the type do 
>> not share access between themselves:
>> 
>> But I agree this should be changed if there is no major technical reason 
>> against it.
> 
> I'm not aware of any technical reason why extensions in the same file should 
> not have access to each other's members.
> 
> John.
> 
>> 
>>> It leaves scoped access working as in Swift 3 in exactly the case where it 
>>> is least useful.  We cannot place stored properties in any extensions, let 
>>> alone extensions in a file other than the one containing the original 
>>> declaration.  
>>> 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://list

[swift-evolution] SE-163: String Revision: Collection Conformance, C Interop, Transcoding

[David Beck via swift-evolution]

> Hello, Swift community!
> 
> The review of "SE-163: String Revision: Collection Conformance, C Interop, 
> Transcoding" begins now and runs through next Tuesday, April 11th. The 
> proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
> 
> Reply text
> 
> Other replies
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> • What is your evaluation of the proposal?

Looks great! Removing collection conformance from String made sense to me 
initially, but in practice is just an arbitrary barrier. It is just too common 
that you need to treat a string like a collection.

> • Is the problem being addressed significant enough to warrant a change to 
> Swift?

Yes.

> • Does this proposal fit well with the feel and direction of Swift?

Absolutely. I love that substring behavior is becoming more obvious. Before the 
Strings manifesto I had no idea that substrings referenced the original string. 
For many operations, a substring will be consumed and then discarded, so non 
copying is what you want. Other times, you are discarding the original and 
keeping the copy, in which case the language pushes you towards creating a 
copy, even if the programmer isn’t aware of what they are doing (I’ve seen this 
with collections). And, very occasionally, it makes sense to keep the 
subcollection around if you are also referencing the original.

This design has been proven to me to be the best of all worlds with collections.

> • If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?

> • How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

a quick reading

> 
> More information about the Swift evolution process is available at 
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> John McCall
> Review Manager
> 
> 
>  


David Beck
dav...@acst.com
http://www.acstechnologies.com

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

[swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[David Beck via swift-evolution]

> Hello Swift community,
> 
> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
> Swift" begins now and runs through April 9, 2017. The revised proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
> The core team’s feedback from the first review of this proposal can be viewed 
> at:
> 
> https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
> Reply text
> Other replies
> What
>  goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?

I’m a very big fan of solving this problem, and this seems like a pretty 
flexible solution for the future.

I like the “::” solution, but could live with the proposed syntax. Also, that 
seems like an aspect that could be changed, either additively, or at the very 
least without breaking ABI stability.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?

YES! While KVO and KVC are big use cases for key paths, other use cases exist 
that make sense for non-objc code to use, especially db related models.

> Does this proposal fit well with the feel and direction of Swift?

For the most part. Like many have said, the slash is a little out of place, but 
hen again, that’s why it was chosen, so that it doesn’t conflict with other 
operators.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?

Most languages that I’ve used this kind of feature with (including ObjC) just 
use stringly typed constructs, which have obvious issues.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

a quick reading

> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> 
>  


David Beck
dav...@acst.com
http://www.acstechnologies.com

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

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[David Waite via swift-evolution]

> On Apr 9, 2017, at 8:44 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> To back up that last point, I ran through the thread and tried to quickly 
> figure out what everyone was thinking. These people seem to be opposed to the 
> proposal: 
> 
>   2. David Waite wants a suite of different, orthogonal string literal 
> features to get enough flexibility.

To be totally accurate, I think even amongst the “evolutionaries” there is a 
broad sets of requirements, and without reducing that set of requirements you 
won’t get a single approach with enough flexibility to meet everyone’s needs.

If the goal was a minimal set of options, it would probably require us to 
determine a set of (I’m guessing three) use cases that multi-line string 
literals are desired for, and attempting syntax for each of those.

An example use which might or might not make the cut:

"When building email responses or a command-line app, I want to make sure I 
control the formatting of output messages such that they fit properly on an 
80-column-width terminal. I am developing in a text editor that displays a 
ruler at the 80 column mark and uses a monospaced font. I thus want to output 
text so that it has no prefix character and is unindented, starting at column 
0. Ideally, the text can be copied/pasted without syntax-driven changes, so 
that I can send it around for external content edits. 

As I typically write command-line apps as swift files rather than compiled into 
binaries, it is desirable to have the text self-contained, rather than as an 
external resource”

(I suspect a similar use case is the motivation behind python’s syntax)

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

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Adrian Zubarev via swift-evolution]

I think you could make it easier for everyone no matter what’s the indent 
preference is, spaces, tabs or even mixed. The closing """ delimiter determine 
the indent for every line before it. Basically it will always look at the 
beginning of that line and take all space characters (except escaped ones) 
until it find first non spacing character or itself.

"""\↵
a\↵
b\↵
c··"""

// result

abc··
Mixed:

"""\↵
·⇥⇥·a\↵
·⇥⇥·b\↵
·⇥⇥·c··"""

// result

abc··
"""\↵
·⇥⇥·a\↵
·⇥⇥·b\↵
·⇥⇥·c··\↵
"""

// result

·⇥⇥·a·⇥⇥·b·⇥⇥·c··
"""\↵
·⇥⇥·a\↵
·⇥⇥·b\↵
·⇥⇥·c··\↵
·⇥"""

// result

⇥·a⇥·b⇥·c··
"""\↵
·⇥⇥·a\↵
·⇥⇥·b\↵
·⇥⇥·c··\↵
·⇥··"""

// shows 3 warning for the line with `a`, `b` and `c`
// fix-it to replace `⇥·` with `··`


-- 
Adrian Zubarev
Sent with Airmail

Am 11. April 2017 um 19:06:01, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

Can you elaborate a small example please, so I can better understand what you 
asked for?



-- 
Adrian Zubarev
Sent with Airmail

Am 11. April 2017 um 18:51:45, Ricardo Parada (rpar...@mac.com) schrieb:



Hi Adrian,

I think having the closing """ on a line by itself activates the indentation 
stripping feature. So if it was to change as you suggest then how would you 
turn off indentation stripping?



On Apr 11, 2017, at 11:08 AM, Adrian Zubarev via swift-evolution 
 wrote:

This would be consistent and less confusing to learn.

Can’t we make the indent algorithm work like this instead?
let string = """\↵
↵
··content text↵
""" // Indent starts with the first non space character

// result

↵
··content text↵

The line where the closing delimiter is trims all space chapters and the indent 
for the whole multi-line string is starting at the point where the first 
non-space chapters is in that line.

What do you think?

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

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[David Waite via swift-evolution]

On Apr 9, 2017, at 7:04 PM, Jose Cheyo Jimenez via swift-evolution 
 wrote:
> 
> On Apr 8, 2017, at 5:19 AM, Neil via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> I agreed with Charlie, but I think there’s another option. 
>> 
>> The access control problems that both SE-0159 and SE-0169 are attempting to 
>> address can be resolved not by changing the definition of the existing 
>> access modifiers, but refocussing the use of extensions. 
>> 
>> One such way would be to introduce a `partial` modifier. It would be similar 
>> to C#’s partial modifier. The proposed partial modifier would be purely 
>> additive and it would go a long way to mitigate the access control issues 
>> inherent in extension-oriented design. 
>> 
>> The key characteristics of partial-oriented design would be:
>> 
>> - Partials would allow the splitting of implementations into multiple 
>> logical units without the same-file restriction.
> 
> I really like the idea of partial but it would need to be restricted to the 
> same file. This would allow partial to just be a compile time feature which 
> just zips up a type together.  Another great feature would be that it could 
> allow stored properties because it is only a compile time feature. Partial 
> could be used to communicate to the user that this type has additional 
> members and properties declared somewhere else in the file. 
> 
> +1 for file scope partial. 

Partials from a C# sense only really shine when they are cross-file, same 
module. Then, preprocessing rules can turn something like a language 
description, XML-based language or extended HTML markup into property 
definitions and template rendering code. A type is partially user code, 
partially generated code.

Other languages may support this via the preprocessor-generated code being a 
super type or subtype of the user code type, but then you necessarily aren’t a 
peer - either a super type preprocessor class can’t see the user methods to 
hook in things like actions and actions, or the user class can’t access 
properties and methods declared by the preprocessor. In both cases, the root 
type usually winds up being declared abstract.

I don’t know what a same-file partial would be, other than an extension which 
also contributes to storage requirements of the type.

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

Re: [swift-evolution] [pitch] Adding in-place removeAll to the std lib

[Guillaume Lessard via swift-evolution]

> On Apr 10, 2017, at 13:30, Kevin Nattinger via swift-evolution 
>  wrote:
> 
> array.remove(where: { $0 > 3 })
> array.remove { $0 > 3 }

`where` is the best label for this.

`filter` doesn’t have an overload for Comparable, this doesn’t need one either.

Cheers,
Guillaume Lessard

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

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Adrian Zubarev via swift-evolution]

Can you elaborate a small example please, so I can better understand what you 
asked for?



-- 
Adrian Zubarev
Sent with Airmail

Am 11. April 2017 um 18:51:45, Ricardo Parada (rpar...@mac.com) schrieb:



Hi Adrian,

I think having the closing """ on a line by itself activates the indentation 
stripping feature. So if it was to change as you suggest then how would you 
turn off indentation stripping?



On Apr 11, 2017, at 11:08 AM, Adrian Zubarev via swift-evolution 
 wrote:

This would be consistent and less confusing to learn.

Can’t we make the indent algorithm work like this instead?
let string = """\↵
↵
··content text↵
""" // Indent starts with the first non space character

// result

↵
··content text↵

The line where the closing delimiter is trims all space chapters and the indent 
for the whole multi-line string is starting at the point where the first 
non-space chapters is in that line.

What do you think?

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

Re: [swift-evolution] Enhancing access levels without breaking changes

[John McCall via swift-evolution]

> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
> On 11 Apr 2017, at 16:27, Matthew Johnson  > wrote:
> 
>> 
>> 
>> Sent from my iPad
>> 
>> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
 On 11 Apr 2017, at 13:29, Jonathan Hull >>> > wrote:
 
> 
> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> On 11 Apr 2017, at 09:40, John McCall  > wrote:
> 
>>> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Sent from my iPhone
>>> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
 I have not voted in favor or against the proposal. I have been reading 
 a lot of responses but I agree with Tony. 
 
 When I started reading the proposal everything was more or less fine 
 half way through the proposal because it was reverting private to 
 fileprivate between the type and its extensions within the same file. 
 I said, if you think of the type and its extensions as a unit then it 
 makes sense. I can explain that. 
 
 Then it started describing a different behavior among the extensions 
 located in a file separate from the file containing the definition of 
 the type. That just started a whole debate inside my head and I 
 understand the passionate responses on both sides. 
 
 But then I imagined myself explaining this to someone new to Swift and 
 it just doesn't seem right. If it becomes convoluted then that's a red 
 flag that it does not belong in Swift. 
>>> 
>>> I understand what you are saying and I wouldn't be against relaxing 
>>> that requirement (not talking for Chris here).
>>> 
>>> The model would change from "Types share scopes with their extensions 
>>> in the same file the type was defined" to "Types and their extensions 
>>> share the same scope in each file".
>> 
>> Oh, I had missed that somehow.  I agree that that is a very strange 
>> rule.  Do you know why it was proposed that way?
> 
> We had to take a stance and Chris seemed to prefer the rule that was 
> proposed. I didn't press because I'm sure he has reasons for preferring 
> it that way. But I have a preference for generalizing visibility to all 
> extensions, even to those in a different file than the type.
 
 I think there is a technical limitation if the visibility goes beyond the 
 compilation unit (unless whole module optimization is turned on).
>>> 
>>> I’m not suggesting visibility beyond the compilation unit. That would break 
>>> the hierarchy of visibility layers: accessibility levels have always been 
>>> contained in one-another and that’s why you can go from private, to 
>>> fileprivate, to internal, to public, to open (but not the other way round) 
>>> without the risk of any compilation error. If all scopes of a type were 
>>> visible to each other (whatever the file), you could not go from private to 
>>> fileprivate.
>>> 
>>> I’m talking about extensions of the same type in the same file (but in a 
>>> separate file from the type) to be able to share private members:
>>> 
>>> Type.swift
>>> 
>>> struct A {
>>> }
>>> 
>>> Other.swift
>>> 
>>> extension A {
>>> func foo() {
>>> bar()
>>> }
>>> }
>>> 
>>> extension A {
>>> private func bar() {
>>> }
>>> }
>>> 
>> 
>> If this is not how your proposal already works I missed that aspect earlier 
>> and find it extremely perplexing (which is probably why I missed it).
> 
> It's mentioned in the Derailed design section:
> 
> This proposal does not change the behavior of extensions that are not in the 
> same file as the type - i.e., extensions in a seperate file to the type do 
> not share access between themselves:
> 
> But I agree this should be changed if there is no major technical reason 
> against it.

I'm not aware of any technical reason why extensions in the same file should 
not have access to each other's members.

John.

> 
>> It leaves scoped access working as in Swift 3 in exactly the case where it 
>> is least useful.  We cannot place stored properties in any extensions, let 
>> alone extensions in a file other than the one containing the original 
>> declaration.  
>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
> ___
> swift-evolution m

Re: [swift-evolution] Reduce with inout

[Daniel Duan via swift-evolution]

Ping.

What’s the latest on this proposal? Seems like a clear win to me. It seems the 
thread converged on a name if we want 2 versions of reduce. Should we simply 
replace the existing version so there’s only one?

Really wish this can get in Swift 4.
> On Jan 25, 2017, at 1:06 AM, Chris Eidhof via swift-evolution 
>  wrote:
> 
> I like it too! Thanks Pyry! Will change the proposal.
> 
> On Wed, Jan 25, 2017 at 8:09 AM, David Hart via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Yep, that's really good.
> 
> On 25 Jan 2017, at 08:00, Jonathan Hull via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> +1  Best so far.
>> 
>>> On Jan 24, 2017, at 10:36 AM, Pyry Jahkola via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
>>> Freak Show wrote:
>>> 
 Am I the only one who finds this incredibly ugly and hard to read?
 
 This is more or less solved by inject:into: idiom.  There is no reason for 
 inout for this particular problem.
>>> 
>>> Yeah, the original signature seems more useful. If you go all `inout` like 
>>> Gwendal suggested, you might as well just iterate over the sequence with 
>>> `for x in xs`, updating the state as you go.
>>> 
>>> But your comment brought another idea to mind: if `mutating:` is considered 
>>> a bad name for a non-`inout` argument, how about `reduce(into:combine:)`, 
>>> similar to what Karl suggested earlier in this thread?
>>> 
>>> I think it reads very well at the call site, does not suggest `inout`ness 
>>> of the argument too much (of course there's no `&` at the call site 
>>> either), and it's still easily found with auto-completion:
>>> 
>>> let counts = words.reduce(into: [:]) {
>>>   $0[$1] = ($0[$1] ?? 0) + 1
>>> }
>>> 
>>> — Pyry
>>> ___
>>> 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 
> 
> 
> 
> 
> 
> -- 
> Chris Eidhof
> ___
> 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] [Review] SE-0168: Multi-Line String Literals

[Ricardo Parada via swift-evolution]

Hi Adrian,

I think having the closing """ on a line by itself activates the indentation 
stripping feature. So if it was to change as you suggest then how would you 
turn off indentation stripping?



> On Apr 11, 2017, at 11:08 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> This would be consistent and less confusing to learn.
> 
> Can’t we make the indent algorithm work like this instead?
> let string = """\↵
> ↵
> ··content text↵
> """ // Indent starts with the first non space character
> 
> // result
> 
> ↵
> ··content text↵
> 
> The line where the closing delimiter is trims all space chapters and the 
> indent for the whole multi-line string is starting at the point where the 
> first non-space chapters is in that line.
> 
> What do you think?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 6, 2017, at 4:25 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> Strong -1. This is a source breaking change, but Swift 4 stage 2 is already 
> over.

I agree with you here. I don't think the proposal will be accepted as is, 
because of the breaking change. 

What if there was a way to make this a new feature so it is not a breaking 
change?

I can see this same proposal being accepted if it was revised to mark the new 
extension behavior explicitly.

Type.swift

struct A { 
private func foo() {}
}

*partial* extension A {  // any other keyword would do here or even \
func baz() {
foo()  // okay 
}
}

extension A {
func boo() {
foo()  // error. Same as swift 3.
}
}

Other.swift

*partial* extension A {  // error. Partial extensions only allowed within the 
declaring file. 
}

extension A {
func boo() {
foo()  // error. Same as swift 3.
}
}



> 
> Slava
> 
>> On Apr 6, 2017, at 4:10 PM, Douglas Gregor > > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0169 "Improve Interaction Between private Declarations and 
>> Extensions" begins now and runs through April 11, 2017. The proposal is 
>> available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>>  
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>>  
>> 
>> Reply text
>> Other replies
>>  
>> What
>>  goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>> What is your evaluation of the proposal?
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> Does this proposal fit well with the feel and direction of Swift?
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> Thank you,
>> 
>> -Doug
>> 
>> Review Manager
>> 
>> ___
>> swift-evolution-announce mailing list
>> swift-evolution-annou...@swift.org 
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce 
>> 
> 
> ___
> 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] [Accepted] SE-0162 Package Manager Custom Target Layouts

[Rick Ballard via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0162-package-manager-custom-target-layouts.md

The review of SE-0162 "Package Manager Custom Target Layouts" ran from April 
4th until April 10th. The proposal is accepted.

The feedback we received prior to and during the review was very positive.

Thanks to everyone who participated!

- Rick Ballard

Review Manager

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

Re: [swift-evolution] switch must be exhaustive, consider adding a default clause

[Joe Groff via swift-evolution]

> On Apr 8, 2017, at 11:29 AM, Drew Crawford via swift-evolution 
>  wrote:
> 
> 
> 
> Is there a good reason we do not compile this:
> 
> import UIKit
> 
> func foo(operation: UINavigationControllerOperation) {
> switch(operation) {
> case .push: /* snip */ break
> case .pop: /* snip */ break
> default:
> preconditionFailure("This is a silly operation")
> }
> switch(operation) {
> case .push: /* snip */ break
> case .pop: /* snip */ break
>  //error: Switch must be exhaustive, consider adding a default clause
> }
> }
> The switch *is* exhaustive, because the default case is unreachable.  The 
> compiler could infer as much from branch analysis
> 
> 

By design, Swift avoids making semantic rules based on that kind of analysis, 
since it would be brittle and difficult to describe when the compiler can and 
can't see that a condition holds nonlocally like this.

-Joe

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

Re: [swift-evolution] Enhancing access levels without breaking changes

[David Hart via swift-evolution]

> On 11 Apr 2017, at 16:27, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
>>  wrote:
>> 
>> 
 On 11 Apr 2017, at 13:29, Jonathan Hull  wrote:
 
 
 On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
  wrote:
 
 On 11 Apr 2017, at 09:40, John McCall  wrote:
 
>> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>>  wrote:
>> 
>> Sent from my iPhone
>> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>>  wrote:
>> 
>>> I have not voted in favor or against the proposal. I have been reading 
>>> a lot of responses but I agree with Tony. 
>>> 
>>> When I started reading the proposal everything was more or less fine 
>>> half way through the proposal because it was reverting private to 
>>> fileprivate between the type and its extensions within the same file. I 
>>> said, if you think of the type and its extensions as a unit then it 
>>> makes sense. I can explain that. 
>>> 
>>> Then it started describing a different behavior among the extensions 
>>> located in a file separate from the file containing the definition of 
>>> the type. That just started a whole debate inside my head and I 
>>> understand the passionate responses on both sides. 
>>> 
>>> But then I imagined myself explaining this to someone new to Swift and 
>>> it just doesn't seem right. If it becomes convoluted then that's a red 
>>> flag that it does not belong in Swift. 
>> 
>> I understand what you are saying and I wouldn't be against relaxing that 
>> requirement (not talking for Chris here).
>> 
>> The model would change from "Types share scopes with their extensions in 
>> the same file the type was defined" to "Types and their extensions share 
>> the same scope in each file".
> 
> Oh, I had missed that somehow.  I agree that that is a very strange rule. 
>  Do you know why it was proposed that way?
 
 We had to take a stance and Chris seemed to prefer the rule that was 
 proposed. I didn't press because I'm sure he has reasons for preferring it 
 that way. But I have a preference for generalizing visibility to all 
 extensions, even to those in a different file than the type.
>>> 
>>> I think there is a technical limitation if the visibility goes beyond the 
>>> compilation unit (unless whole module optimization is turned on).
>> 
>> I’m not suggesting visibility beyond the compilation unit. That would break 
>> the hierarchy of visibility layers: accessibility levels have always been 
>> contained in one-another and that’s why you can go from private, to 
>> fileprivate, to internal, to public, to open (but not the other way round) 
>> without the risk of any compilation error. If all scopes of a type were 
>> visible to each other (whatever the file), you could not go from private to 
>> fileprivate.
>> 
>> I’m talking about extensions of the same type in the same file (but in a 
>> separate file from the type) to be able to share private members:
>> 
>> Type.swift
>> 
>> struct A {
>> }
>> 
>> Other.swift
>> 
>> extension A {
>> func foo() {
>> bar()
>> }
>> }
>> 
>> extension A {
>> private func bar() {
>> }
>> }
> 
> If this is not how your proposal already works I missed that aspect earlier 
> and find it extremely perplexing (which is probably why I missed it).

It's mentioned in the Derailed design section:

This proposal does not change the behavior of extensions that are not in the 
same file as the type - i.e., extensions in a seperate file to the type do not 
share access between themselves:

But I agree this should be changed if there is no major technical reason 
against it.

> It leaves scoped access working as in Swift 3 in exactly the case where it is 
> least useful.  We cannot place stored properties in any extensions, let alone 
> extensions in a file other than the one containing the original declaration.  
> 
>> 
>> ___
>> 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] [Review] SE-0168: Multi-Line String Literals

[Adrian Zubarev via swift-evolution]

That’s also the example that kept me thinking for a while.

Overall the proposal is a great compromise to some issues I had with the first 
version. However I have a few more questions:

Why can’t we make it consistent and let the compiler add a new line after the 
starting delimiter.

let string = """↵
Swift↵
"""

// result
↵Swift↵
If one would would the behavior from the proposal it’s really easy to add a 
backslash after the starting delimiter.


let string = """\↵
Swift\↵
"""

// result
Swift
This would be consistent and less confusing to learn.

Can’t we make the indent algorithm work like this instead?
let string = """\↵
↵
··content text↵
""" // Indent starts with the first non space character

// result

↵
··content text↵

The line where the closing delimiter is trims all space chapters and the indent 
for the whole multi-line string is starting at the point where the first 
non-space chapters is in that line.

What do you think?

PS: If we’d get this feature in Swift, it would be nice if Xcode and other IDEs 
which supports Swift could show space characters that are inside a string 
literal (not other space character <- which is already supported), so it would 
be easier to tell what’s part of the string and what is not.



-- 
Adrian Zubarev
Sent with Airmail

Am 11. April 2017 um 16:33:28, Vladimir.S via swift-evolution 
(swift-evolution@swift.org) schrieb:

On 11.04.2017 16:35, John Holdsworth via swift-evolution wrote:
> I feel discussion on this proposal is nearing general agreement that while 
> the gist of it
> it seems reasonable to many there is also not enough detail in it as 
> submitted.
>
> Brent has person-fully stepped in and rewritten the draft to translate it 
> into a detailed
> specification which I’ve updated here:
>
> https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md

Thank you for the detailed proposal.
FWIW, in general I support it, but have two objections/questions:

1. "Tripled string literals support backslash escapes and interpolation as 
normal,  
except that you can also place a backslash immediately before a newline. This  
indicates that the newline is merely for code formatting and should not be 
present in  
the resulting string:"
- I think this a confusion point which should not be in this proposal. 
Currently in  
"normal" strings we just can't have single backlash as it will generate 
"invalid  
escape sequence in literal" warning.
Is this feature worth the added complexity? I'm not sure currently.

2. Seems like a mistake:
"Multi-line string with indentation stripping prevented by whitespace before 
leading  
newline"

"""↵
Hello↵
world!"""

Creates a string with:

↵
Hello↵
world!

I believe it should be just:

Hello↵
world!

>
> Perhaps we could use the remaining time on the review to pre-evaluate this 
> draft should
> we get the chance to resubmit with modifications to maximise its chances. Key 
> questions:
>
> 1) Does Swift need multi-line string literals?
> 2 ) Is “””long strings””” the way to go subject to a discussion about the 
> precise
> delimiter
> 3) Is the “magic" leading whitespace removal a good idea to support 
> indentation.
>
> The main change on the revised proposal from the the original submitted is 
> Thorsten’s
> suggestion that Windows line endings in a source file be normalised to \n in 
> the literal.
>
> John
>
>> On 10 Apr 2017, at 12:09, Thorsten Seitz > > wrote:
>>
>>
>>> Am 09.04.2017 um 18:29 schrieb John Holdsworth >> >:
>>>
>>> Hi, John here, the submitter of the proposal.
>>>
>>> First up, I must apologise for putting Brent on the spot when I resubmitted 
>>> this
>>> altered proposal from last year. That was my mistake.
>>>
>>> Second up, apologies if the proposal is rather vague on details. In some 
>>> sense
>>> this was intentional as I didn’t want to get too bogged down in specifics 
>>> (and not
>>> at all to do with my limitations as a technical writer!)
>>>
>>> I guess we need to build up consensus more slowly by asking the following
>>> questions separately so it can be resubmitted rather than giving a binary 
>>> +/-1 on
>>> the proposal as it stands.
>>>
>>> 1) Does Swift need multi-line string literals?
>>
>> Yes.
>>
>>> 2 ) Is “””long strings””” the way to go subject to a discussion about the 
>>> precise
>>> delimiter
>>
>> Yes.
>>
>>> 3) Is the “magic" leading whitespace removal a good idea to support 
>>> indentation.
>>
>> Yes.
>>
>>> 4) Does the proposal contain sufficient detail to be discussed/implemented
>>
>> Thanks for the update! I only have the following issues left:
>>
>> > All other escapes would be processed as before including interpolation, \n 
>> > and "
>> You probably meant \“ instead of " here.
>>
>> The proposal should state what kind of newline will be used within a 
>> multiline
>> string literal. I already proposed that it 

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Vladimir.S via swift-evolution]

On 11.04.2017 16:35, John Holdsworth via swift-evolution wrote:

I feel discussion on this proposal is nearing general agreement that while the 
gist of it
it seems reasonable to many there is also not enough detail in it as submitted.

Brent has person-fully stepped in and rewritten the draft to translate it into 
a detailed
specification which I’ve updated here:

https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md


Thank you for the detailed proposal.
FWIW, in general I support it, but have two objections/questions:

1. "Tripled string literals support backslash escapes and interpolation as normal, 
except that you can also place a backslash immediately before a newline. This 
indicates that the newline is merely for code formatting and should not be present in 
the resulting string:"
- I think this a confusion point which should not be in this proposal. Currently in 
"normal" strings we just can't have single backlash as it will generate "invalid 
escape sequence in literal" warning.

Is this feature worth the added complexity? I'm not sure currently.

2. Seems like a mistake:
"Multi-line string with indentation stripping prevented by whitespace before leading 
newline"


"""↵
Hello↵
world!"""

Creates a string with:

↵
Hello↵
world!

I believe it should be just:

Hello↵
world!



Perhaps we could use the remaining time on the review to pre-evaluate this 
draft should
we get the chance to resubmit with modifications to maximise its chances. Key 
questions:

1) Does Swift need multi-line string literals?
2 ) Is “””long strings””” the way to go subject to a discussion about the 
precise
delimiter
3) Is the “magic" leading whitespace removal a good idea to support indentation.

The main change on the revised proposal from the the original submitted is 
Thorsten’s
suggestion that Windows line endings in a source file be normalised to \n in 
the literal.

John


On 10 Apr 2017, at 12:09, Thorsten Seitz mailto:tseit...@icloud.com>> wrote:



Am 09.04.2017 um 18:29 schrieb John Holdsworth mailto:m...@johnholdsworth.com>>:

Hi, John here, the submitter of the proposal.

First up, I must apologise for putting Brent on the spot when I resubmitted this
altered proposal from last year. That was my mistake.

Second up, apologies if the proposal is rather vague on details. In some sense
this was intentional as I didn’t want to get too bogged down in specifics (and 
not
at all to do with my limitations as a technical writer!)

I guess we need to build up consensus more slowly by asking the following
questions separately so it can be resubmitted rather than giving a binary +/-1 
on
the proposal as it stands.

1) Does Swift need multi-line string literals?


Yes.


2 ) Is “””long strings””” the way to go subject to a discussion about the 
precise
delimiter


Yes.


3) Is the “magic" leading whitespace removal a good idea to support indentation.


Yes.


4) Does the proposal contain sufficient detail to be discussed/implemented


Thanks for the update! I only have the following issues left:

> All other escapes would be processed as before including interpolation, \n and 
"
You probably meant \“ instead of " here.

The proposal should state what kind of newline will be used within a multiline
string literal. I already proposed that it should be exactly the same as for \n 
and
not the newline character(s) actually used in the file (e.g. LF+CR or LF or 
CR), to
avoid issues when working on different platforms (Windows, Mac, Linux) and/or 
using
Git’s autocrlf feature.

The proposal should give an example how to create a multiline string literal 
which
ends with a newline (AFAIU there should be an empty line before the closing 
""“).

-Thorsten



My answer to 1) is obviously yes and I think the discussion has come out about
50/50 so far so lets persevere...

Trying to fie down 2), a “””long string””” or @“long string”@ or _”long string”_
or #”long string”# is a string literal inside a new delimiter. It would be
processed exactly as it would a normal string including escapes and 
interpolation
except the string can include unescaped “ or  “" and newlines. Also, a \ at the
end of the line would mean that particular newline is not included in the 
string.

For me, the goals of a long string are that it should be able to pasted in
(almost) without modification from a text source and that syntax highlighting
would work for the widest possible range of text editors and github. “””long
string””” is just a trick Python uses to satisfy the second goal (for example 
this
gist
)
 but
highlighting also works for asymmetric delimiters such as @“long string”@ which
avoid potential problems with “inversion”. Heredoc or a Swifty #equivalent does
not satisfy this second goal at all well and IMHO it should be excluded. It 
would
also be significantly more difficult to

Re: [swift-evolution] Enhancing access levels without breaking changes

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
>>> On 11 Apr 2017, at 13:29, Jonathan Hull  wrote:
>>> 
>>> 
>>> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> On 11 Apr 2017, at 09:40, John McCall  wrote:
>>> 
> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>  wrote:
> 
> Sent from my iPhone
> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>  wrote:
> 
>> I have not voted in favor or against the proposal. I have been reading a 
>> lot of responses but I agree with Tony. 
>> 
>> When I started reading the proposal everything was more or less fine 
>> half way through the proposal because it was reverting private to 
>> fileprivate between the type and its extensions within the same file. I 
>> said, if you think of the type and its extensions as a unit then it 
>> makes sense. I can explain that. 
>> 
>> Then it started describing a different behavior among the extensions 
>> located in a file separate from the file containing the definition of 
>> the type. That just started a whole debate inside my head and I 
>> understand the passionate responses on both sides. 
>> 
>> But then I imagined myself explaining this to someone new to Swift and 
>> it just doesn't seem right. If it becomes convoluted then that's a red 
>> flag that it does not belong in Swift. 
> 
> I understand what you are saying and I wouldn't be against relaxing that 
> requirement (not talking for Chris here).
> 
> The model would change from "Types share scopes with their extensions in 
> the same file the type was defined" to "Types and their extensions share 
> the same scope in each file".
 
 Oh, I had missed that somehow.  I agree that that is a very strange rule.  
 Do you know why it was proposed that way?
>>> 
>>> We had to take a stance and Chris seemed to prefer the rule that was 
>>> proposed. I didn't press because I'm sure he has reasons for preferring it 
>>> that way. But I have a preference for generalizing visibility to all 
>>> extensions, even to those in a different file than the type.
>> 
>> I think there is a technical limitation if the visibility goes beyond the 
>> compilation unit (unless whole module optimization is turned on).
> 
> I’m not suggesting visibility beyond the compilation unit. That would break 
> the hierarchy of visibility layers: accessibility levels have always been 
> contained in one-another and that’s why you can go from private, to 
> fileprivate, to internal, to public, to open (but not the other way round) 
> without the risk of any compilation error. If all scopes of a type were 
> visible to each other (whatever the file), you could not go from private to 
> fileprivate.
> 
> I’m talking about extensions of the same type in the same file (but in a 
> separate file from the type) to be able to share private members:
> 
> Type.swift
> 
> struct A {
> }
> 
> Other.swift
> 
> extension A {
> func foo() {
> bar()
> }
> }
> 
> extension A {
> private func bar() {
> }
> }
> 

If this is not how your proposal already works I missed that aspect earlier and 
find it extremely perplexing (which is probably why I missed it).  It leaves 
scoped access working as in Swift 3 in exactly the case where it is least 
useful.  We cannot place stored properties in any extensions, let alone 
extensions in a file other than the one containing the original declaration.  

> 
> ___
> 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] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Gwendal Roué via swift-evolution]

> Le 8 avr. 2017 à 00:45, Jordan Rose  a écrit :
> 
> 
>> On Apr 7, 2017, at 04:18, Gwendal Roué via swift-evolution 
>>  wrote:
>> 
>> - the private/fileprivate qualifier used not to be a intrinsic property of 
>> an object (because one had to move from private to fileprivate as soon as an 
>> extension was added). Now private/fileprivate can be made meaningful, and 
>> above all *stable*. A scenario where private is turned into a fileprivate 
>> now involves something called "friendship" in C++: fileprivate now reflects 
>> *actual design intent*, not "shut up this stupid compiler".
> 
> I, uh, wish to object to your implication that C++ 'friend' reflects actual 
> design intent in most cases. :-)

I have used C++ `friend`, like 15 years ago, and I can't say I lack it today!

Still, under this proposal, Swift's `fileprivate` will cover some use cases of 
C++ `friend`, and also `protected`: after all, some blessed types or subclasses 
will have access to some otherwise unavailable members. If I'm right, we should 
see "Swift fileprivate considered harmful" posts sooner or later :-)

BTW - I've just realized that I've voted twice on this proposal - apologies!

Gwendal

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

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Gwendal Roué via swift-evolution]

>   • What is your evaluation of the proposal?

Positive.

I could not stress enough how the attitude behind such a proposal is *positive*.

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes. private / fileprivate had a tremendous design issue: developers would jump 
from private to fileprivate just to shut up the compiler. Now this won't happen 
unless an actual design decision.

>   • Does this proposal fit well with the feel and direction of Swift?

Yes.

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

Reasonably well.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Have pity. It's very difficult to follow this topic that has generated 
thousands of messages. I vote +1 because the proposal looks reasonable, 
balanced, and focused on regular developers. I wish people who insists on 
splitting hairs about access control would give us a break already.

Gwendal Roué


> Le 11 avr. 2017 à 13:00, David Hart via swift-evolution 
>  a écrit :
> 
> 
> On 11 Apr 2017, at 08:48, Tino Heth via swift-evolution 
>  wrote:
> 
>> -1 (strong)
>> 
>> I think I've read all messages and haven't much to add — so just to sum up 
>> my concerns in order:
>> — It makes access control more complicated
>> For me, it's not about the complexity itself (it's not terrible huge, after 
>> all), but I believe in the beauty of simplicity, which is already quite 
>> flawed.
>> — It adds no power to the language
>> The proposal solves no real problem, but rather encourages a certain style 
>> of programming, which is quite popular among authors of styleguides, but has 
>> no clear net gain.
> 
> While your other points are defendable, I have to disagree here. It does 
> bring value to a population of developers (me included) for whom that style 
> of programming adds a lot of readability. It's part of style guides for a 
> reason.
> 
>> — It diminishes the need for fileprivate without making it redundant
>> It would be nice to get rid of an access level, but having four common ones 
>> and fileprivate as an exotic outlier doesn't feel right for me.
> 
> Doesn't the argument of progressive disclosure sway you here? open is already 
> an outlier that only library authors will play with, and that's a good thing. 
> It reduces the number of access level truly useful on a day to day basis, 
> while leaving the others for more narrow purposes.
> 
>> — It is a mockery for SE-0025
>> I never liked "new private", but it was decided that this sort of 
>> encapsulation is important enough to justify 33% increase in the number of 
>> access levels, so I don't like to see this watered down
>> — It is a breaking change
>> For me personally, that doesn't really count as an argument on its own, and 
>> I would gladly take the inconvenience of incompatibility in exchange for a 
>> tiny improvement of the language; but in combination with the other points, 
>> it increases opposition.
>> 
>> I spend some time thinking about nested extensions (which would achieve the 
>> goal of this proposal naturally) and think that SE-0169 would lead to some 
>> questionable possibilities of short-circuiting access control:
>> 
>> class Outer {
>>  private class Inner {
>>  private var x = 0
>>  }
>> }
>> 
>> /*
>> .
>> .
>> .
>> */
>> 
>> extension Outer.Inner {
>>  public func f() {
>>  print(x)
>>  }
>> }
>> 
>> As I read the proposal, there is no doubt that this would be allowed — but 
>> without that detailed information, I'm not sure if anybody would expect that 
>> two levels of private still is not enough to keep something secret…
>> 
>> - Tino
>> ___
>> 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] Enhancing access levels without breaking changes

[David Hart via swift-evolution]

> On 11 Apr 2017, at 13:29, Jonathan Hull  wrote:
> 
>> 
>> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> On 11 Apr 2017, at 09:40, John McCall > > wrote:
>> 
 On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Sent from my iPhone
 On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
> I have not voted in favor or against the proposal. I have been reading a 
> lot of responses but I agree with Tony. 
> 
> When I started reading the proposal everything was more or less fine half 
> way through the proposal because it was reverting private to fileprivate 
> between the type and its extensions within the same file. I said, if you 
> think of the type and its extensions as a unit then it makes sense. I can 
> explain that. 
> 
> Then it started describing a different behavior among the extensions 
> located in a file separate from the file containing the definition of the 
> type. That just started a whole debate inside my head and I understand 
> the passionate responses on both sides. 
> 
> But then I imagined myself explaining this to someone new to Swift and it 
> just doesn't seem right. If it becomes convoluted then that's a red flag 
> that it does not belong in Swift. 
 
 I understand what you are saying and I wouldn't be against relaxing that 
 requirement (not talking for Chris here).
 
 The model would change from "Types share scopes with their extensions in 
 the same file the type was defined" to "Types and their extensions share 
 the same scope in each file".
>>> 
>>> Oh, I had missed that somehow.  I agree that that is a very strange rule.  
>>> Do you know why it was proposed that way?
>> 
>> We had to take a stance and Chris seemed to prefer the rule that was 
>> proposed. I didn't press because I'm sure he has reasons for preferring it 
>> that way. But I have a preference for generalizing visibility to all 
>> extensions, even to those in a different file than the type.
> 
> I think there is a technical limitation if the visibility goes beyond the 
> compilation unit (unless whole module optimization is turned on).

I’m not suggesting visibility beyond the compilation unit. That would break the 
hierarchy of visibility layers: accessibility levels have always been contained 
in one-another and that’s why you can go from private, to fileprivate, to 
internal, to public, to open (but not the other way round) without the risk of 
any compilation error. If all scopes of a type were visible to each other 
(whatever the file), you could not go from private to fileprivate.

I’m talking about extensions of the same type in the same file (but in a 
separate file from the type) to be able to share private members:

Type.swift

struct A {
}

Other.swift

extension A {
func foo() {
bar()
}
}

extension A {
private func bar() {
}
}


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

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

[Adrian Zubarev via swift-evolution]

I myself pitched that requirement quite a few times on the list. Thank you, 
finally I understood why it’s not possible. Now I fully agree that the 
requirement of an override should not exist for the base type conforming to the 
protocol.

For those who might misunderstand the concept of retroactive conformances just 
like I did it, here is a quick snippet for you.

Imagine you’re working on some iOS project and for some reason you need an 
existential that only knows a property title of type String?.

protocol P { var title: String? { get set } }
Now you could retroactively conform types that already have this property to 
that protocol P without the need of implementing the property yourself. Think 
of it as a backdoor. ;)

extension UIViewController : P {} // This just works
The proposed solution will simply break this nice feature.



-- 
Adrian Zubarev
Sent with Airmail

Am 11. April 2017 um 00:52:01, Xiaodi Wu via swift-evolution 
(swift-evolution@swift.org) schrieb:

Requiring `override` breaks retroactive conformance of types to protocols. This 
idea has been brought up over half a dozen times. Each time it fails in not 
being able to accommodate retroactive conformance.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Gwendal Roué via swift-evolution]

Wow, thanks a lot for this detailed rewrite! Looks like something worth 
evaluating now :-)

> Is the “magic" leading whitespace removal a good idea to support indentation.

It's worth mentioning that the updated proposal contains ways to avoid the 
automatic indentation processing.

Gwendal

> Le 11 avr. 2017 à 15:35, John Holdsworth via swift-evolution 
>  a écrit :
> 
> I feel discussion on this proposal is nearing general agreement that while 
> the gist of it
> it seems reasonable to many there is also not enough detail in it as 
> submitted.
> 
> Brent has person-fully stepped in and rewritten the draft to translate it 
> into a detailed
> specification which I’ve updated here:
> 
> https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
>  
> 
> 
> Perhaps we could use the remaining time on the review to pre-evaluate this 
> draft should
> we get the chance to resubmit with modifications to maximise its chances. Key 
> questions:
> 
> 1) Does Swift need multi-line string literals?
> 2 ) Is “””long strings””” the way to go subject to a discussion about the 
> precise delimiter
> 3) Is the “magic" leading whitespace removal a good idea to support 
> indentation.
> 
> The main change on the revised proposal from the the original submitted is 
> Thorsten’s
> suggestion that Windows line endings in a source file be normalised to \n in 
> the literal.
> 
> John
> 
>> On 10 Apr 2017, at 12:09, Thorsten Seitz > > wrote:
>> 
>> 
>>> Am 09.04.2017 um 18:29 schrieb John Holdsworth >> >:
>>> 
>>> Hi, John here, the submitter of the proposal.
>>> 
>>> First up, I must apologise for putting Brent on the spot when I resubmitted 
>>> this altered proposal from last year. That was my mistake.
>>> 
>>> Second up, apologies if the proposal is rather vague on details. In some 
>>> sense this was intentional as I didn’t want to get too bogged down in 
>>> specifics (and not at all to do with my limitations as a technical writer!)
>>> 
>>> I guess we need to build up consensus more slowly by asking the following 
>>> questions separately so it can be resubmitted rather than giving a binary 
>>> +/-1 on the proposal as it stands.
>>> 
>>> 1) Does Swift need multi-line string literals?
>> 
>> Yes.
>> 
>>> 2 ) Is “””long strings””” the way to go subject to a discussion about the 
>>> precise delimiter
>> 
>> Yes.
>> 
>>> 3) Is the “magic" leading whitespace removal a good idea to support 
>>> indentation.
>> 
>> Yes.
>> 
>>> 4) Does the proposal contain sufficient detail to be discussed/implemented
>> 
>> Thanks for the update! I only have the following issues left:
>> 
>> > All other escapes would be processed as before including interpolation, \n 
>> > and "
>> You probably meant \“ instead of " here.
>> 
>> The proposal should state what kind of newline will be used within a 
>> multiline string literal. I already proposed that it should be exactly the 
>> same as for \n and not the newline character(s) actually used in the file 
>> (e.g. LF+CR or LF or CR), to avoid issues when working on different 
>> platforms (Windows, Mac, Linux) and/or using Git’s autocrlf feature.
>> 
>> The proposal should give an example how to create a multiline string literal 
>> which ends with a newline (AFAIU there should be an empty line before the 
>> closing ""“).
>> 
>> -Thorsten
>> 
>>> 
>>> My answer to 1) is obviously yes and I think the discussion has come out 
>>> about 50/50 so far so lets persevere...
>>> 
>>> Trying to fie down 2), a “””long string””” or @“long string”@ or _”long 
>>> string”_ or #”long string”# is a string literal inside a new delimiter. It 
>>> would be processed exactly as it would a normal string including escapes 
>>> and interpolation except the string can include unescaped “ or  “" and 
>>> newlines. Also, a \ at the end of the line would mean that particular 
>>> newline is not included in the string.
>>> 
>>> For me, the goals of a long string are that it should be able to pasted in 
>>> (almost) without modification from a text source and that syntax 
>>> highlighting would work for the widest possible range of text editors and 
>>> github. “””long string””” is just a trick Python uses to satisfy the second 
>>> goal (for example this gist 
>>> )
>>>  but highlighting also works for asymmetric delimiters such as @“long 
>>> string”@ which avoid potential problems with “inversion”. Heredoc or a 
>>> Swifty #equivalent does not satisfy this second goal at all well and IMHO 
>>> it should be excluded. It would also be significantly more difficult to 
>>> integrate into the Swift compiler.
>>> 
>>> Looking at 3) which is underspecified in the proposal perhaps, I’d consider 
>>> it a “feature" but I can se

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[John Holdsworth via swift-evolution]

I feel discussion on this proposal is nearing general agreement that while the 
gist of it
it seems reasonable to many there is also not enough detail in it as submitted.

Brent has person-fully stepped in and rewritten the draft to translate it into 
a detailed
specification which I’ve updated here:

https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
 


Perhaps we could use the remaining time on the review to pre-evaluate this 
draft should
we get the chance to resubmit with modifications to maximise its chances. Key 
questions:

1) Does Swift need multi-line string literals?
2 ) Is “””long strings””” the way to go subject to a discussion about the 
precise delimiter
3) Is the “magic" leading whitespace removal a good idea to support indentation.

The main change on the revised proposal from the the original submitted is 
Thorsten’s
suggestion that Windows line endings in a source file be normalised to \n in 
the literal.

John

> On 10 Apr 2017, at 12:09, Thorsten Seitz  wrote:
> 
> 
>> Am 09.04.2017 um 18:29 schrieb John Holdsworth > >:
>> 
>> Hi, John here, the submitter of the proposal.
>> 
>> First up, I must apologise for putting Brent on the spot when I resubmitted 
>> this altered proposal from last year. That was my mistake.
>> 
>> Second up, apologies if the proposal is rather vague on details. In some 
>> sense this was intentional as I didn’t want to get too bogged down in 
>> specifics (and not at all to do with my limitations as a technical writer!)
>> 
>> I guess we need to build up consensus more slowly by asking the following 
>> questions separately so it can be resubmitted rather than giving a binary 
>> +/-1 on the proposal as it stands.
>> 
>> 1) Does Swift need multi-line string literals?
> 
> Yes.
> 
>> 2 ) Is “””long strings””” the way to go subject to a discussion about the 
>> precise delimiter
> 
> Yes.
> 
>> 3) Is the “magic" leading whitespace removal a good idea to support 
>> indentation.
> 
> Yes.
> 
>> 4) Does the proposal contain sufficient detail to be discussed/implemented
> 
> Thanks for the update! I only have the following issues left:
> 
> > All other escapes would be processed as before including interpolation, \n 
> > and "
> You probably meant \“ instead of " here.
> 
> The proposal should state what kind of newline will be used within a 
> multiline string literal. I already proposed that it should be exactly the 
> same as for \n and not the newline character(s) actually used in the file 
> (e.g. LF+CR or LF or CR), to avoid issues when working on different platforms 
> (Windows, Mac, Linux) and/or using Git’s autocrlf feature.
> 
> The proposal should give an example how to create a multiline string literal 
> which ends with a newline (AFAIU there should be an empty line before the 
> closing ""“).
> 
> -Thorsten
> 
>> 
>> My answer to 1) is obviously yes and I think the discussion has come out 
>> about 50/50 so far so lets persevere...
>> 
>> Trying to fie down 2), a “””long string””” or @“long string”@ or _”long 
>> string”_ or #”long string”# is a string literal inside a new delimiter. It 
>> would be processed exactly as it would a normal string including escapes and 
>> interpolation except the string can include unescaped “ or  “" and newlines. 
>> Also, a \ at the end of the line would mean that particular newline is not 
>> included in the string.
>> 
>> For me, the goals of a long string are that it should be able to pasted in 
>> (almost) without modification from a text source and that syntax 
>> highlighting would work for the widest possible range of text editors and 
>> github. “””long string””” is just a trick Python uses to satisfy the second 
>> goal (for example this gist 
>> )
>>  but highlighting also works for asymmetric delimiters such as @“long 
>> string”@ which avoid potential problems with “inversion”. Heredoc or a 
>> Swifty #equivalent does not satisfy this second goal at all well and IMHO it 
>> should be excluded. It would also be significantly more difficult to 
>> integrate into the Swift compiler.
>> 
>> Looking at 3) which is underspecified in the proposal perhaps, I’d consider 
>> it a “feature" but I can see it would be too magical for some. To specify it 
>> more you could say: if there is only whitespace between the last newline and 
>> the end of a multiline literal this whitespace will be stripped from all 
>> lines in the literal. If lines do not start with this exact sequence of 
>> whitespace a warning is emitted. In addition, if the first character in the 
>> literal is a newline it will be removed. This operation could be made 
>> explicit e.g. #trimLeft(“”"a literal""")
>> 
>> Perhaps we can find common ground on 1) and 2) and even 3

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

[Vladimir.S via swift-evolution]

On 11.04.2017 1:51, Xiaodi Wu via swift-evolution wrote:
> On Mon, Apr 10, 2017 at 5:35 PM, Howard Lovatt via swift-evolution
> mailto:swift-evolution@swift.org>> wrote:
>
> In response to Jordan Rose's comment I suggest the following change:
>
> Proposal: Split extension usage up into implementing methods and adding
> static functions
>
>
> Currently extension methods are confusing because they have different
> dispatch rules for the same syntax. EG:
>
>
> protocol P {
>
> func m()
>
> }
>
> extension P {
>
> func m() { print("P.m") }
>
> }
>
> struct S: P {
>
> func m() { print("S.m") }
>
> }
>
> val p: P = S() // Note typed as P
>
> p.m() // Surprisingly prints P.m even though S implements its own m
>
>
> This is incorrect. This prints "S.m", not "P.m".

I believe the discussion was started is about protocol extensions methods that was 
not declared as protocol requirements:


protocol P {
func foo()
}

struct S : P {
func foo() {print("FOO from S")}
}

//

extension P {
func foo() {print("FOO default implementation from protocol")}

// notice: bar was not declared as protocol requirement
func bar() {print("BAR default implementation from protocol")}
}

extension S {
func bar() {print("BAR from S")}
}

var  p : P = S()
p.foo() // FOO from S
p.bar() // BAR default implementation from protocol

var  s :S = S()
s.foo() // FOO from S
s.bar() // BAR from S

This is actually a big confusion point raised periodically in list and on 
stackoverflow etc. When you know how it works currently - you have no questions, but 
before this you can think that P.bar is same "thing" as P.foo. IMO Swift should help 
to clarify this situation with some kind of keyword/warning or actually make P.bar 
use the same rules as P.foo. After all, P.bar is a method in P protocol, S conforms 
to P protocol, so p.bar() logically should call S.bar() implementation.


At least IMO we need some marker for such protocol extension method that is not 
declared in protocol itself as requirement.


extension P {
func foo() {...}

	func bar() {...} // Warning: 'bar' is not protocol requirement, use 'notrequirement' 
keyword

}

var  p : P = S()
p.foo()
p.bar() // Warning: 'bar' is not-a-requirement method defined without 
'notrequirement' keyword


So, to fix the warning:

extension P {
func foo() {...}

notrequirement func bar() {...}
}

('notrequirement' is not a proposal, just an example)

Personally I'd even require a "marker" on caller side, for example

p.bar() // Warning: 'bar' is not-a-requirement method, exact implementation of 
P.bar() will be called. Use explicit casting to silence the warning


(p as P).bar() // ok


>
>
> val s = S() // Note typed as S
>
> s.m() // Prints S.m as expected
>
>
> This proposal cures the above problem by separating extension methods
> into two seperate use cases: implementations for methods and adding
> static functions.
>
>
> First implementing methods.
>
>
> If the extension is in the same file as the protocol/struct/class
> declaration then it implements the methods and is dispatched using a
> Vtable. EG:
>
>
> File P.swift
>
> protocol/struct/class P {
>
> func m()
>
> }
>
> extension P {
>
> func m() { print("P.m") }
>
> }
>
>
> Same or other file
>
> struct S: P {
>
> override func m() { print("S.m") } // Note override required
> because m already has an implementation from the extension
>
>
> Requiring `override` breaks retroactive conformance of types to protocols.
> This idea has been brought up over half a dozen times. Each time it fails
> in not being able to accommodate retroactive conformance.

FWIW Actually, there were a number of suggestions where this point is solved with 
some additional keywords/syntax. But as I remember they also was not accepted.


IIRC something like this:

protocol P {
func foo()
}

struct S : P {
func foo() {} // no default implementation was known at the moment of
  // *writing* this code
}

//another file

extension P {
func foo() {} // this causes warning for S declaration "'override' is 
missed"
func bar() {} // not-a-requrement
}

extension S {
overriden foo() // silence the warning, notice 'overriden', no body

override bar() {} // so S.bar should be called on S instance typed as P
}


Or this case:

struct S {
func foo() {}
func bar() {}
}

// another file

protocol P {
func foo()
}

extension P {
func foo() {}
func bar() {} // not-a-requrement
}

// another file

extension S : P {
overriden foo() // silence the warning
overriden bar() // silence the warning

  

Re: [swift-evolution] Enhancing access levels without breaking changes

[Jonathan Hull via swift-evolution]

> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
>  wrote:
> 
> On 11 Apr 2017, at 09:40, John McCall  > wrote:
> 
>>> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Sent from my iPhone
>>> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
 I have not voted in favor or against the proposal. I have been reading a 
 lot of responses but I agree with Tony. 
 
 When I started reading the proposal everything was more or less fine half 
 way through the proposal because it was reverting private to fileprivate 
 between the type and its extensions within the same file. I said, if you 
 think of the type and its extensions as a unit then it makes sense. I can 
 explain that. 
 
 Then it started describing a different behavior among the extensions 
 located in a file separate from the file containing the definition of the 
 type. That just started a whole debate inside my head and I understand the 
 passionate responses on both sides. 
 
 But then I imagined myself explaining this to someone new to Swift and it 
 just doesn't seem right. If it becomes convoluted then that's a red flag 
 that it does not belong in Swift. 
>>> 
>>> I understand what you are saying and I wouldn't be against relaxing that 
>>> requirement (not talking for Chris here).
>>> 
>>> The model would change from "Types share scopes with their extensions in 
>>> the same file the type was defined" to "Types and their extensions share 
>>> the same scope in each file".
>> 
>> Oh, I had missed that somehow.  I agree that that is a very strange rule.  
>> Do you know why it was proposed that way?
> 
> We had to take a stance and Chris seemed to prefer the rule that was 
> proposed. I didn't press because I'm sure he has reasons for preferring it 
> that way. But I have a preference for generalizing visibility to all 
> extensions, even to those in a different file than the type.

I think there is a technical limitation if the visibility goes beyond the 
compilation unit (unless whole module optimization is turned on).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0169

[David Hart via swift-evolution]

> On 11 Apr 2017, at 09:24, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On 11 Apr 2017, at 02:41, Michael Mayer via swift-evolution 
>>  wrote:
>> 
>> All -
>> 
>> I am not in favor of this change.  While I agree that the implementation of 
>> fileprivate and open as well as the changes to private had some unintended 
>> by-products, they can easily be accommodated.  Sometimes the language by its 
>> nature dictates style.  I say at this point, we all just need to deal with 
>> it and move on.  We have bigger and more impactful language features to fry. 
>>  
>> 
>> IMHO the changes in this proposal create a host of complications in the 
>> understanding of what can already be a hard to understand topic.  We are 
>> greatly increasing the surface area of what must be learned in order to 
>> completely grok private and fileprivate.
> 
> The goal of progressive disclosure is NOT to reduce the amount of learning 
> you need to get COMPLETE understanding of a topic like access control, but 
> being able to get started easily with a small subset of info and go deeper if 
> you need it and on your terms which this proposal achieves.

Agreed. If this proposal gets accepted, one only needs to learn internal and 
private to work as an application developer, and only later public and open as 
a library other. fileprivate can be learned when necessary, in rarer situation.

>>  This added complexity does not justify what I feel are just cosmetic 
>> improvements to suit a particular coding style.  
>> 
>> Changes such as this to suit a particular coding style, need to be avoided 
>> or we risk losing focus on the definition and implementation of more 
>> critical changes.
>> 
>> I don’t comment on many proposals, but this one stood out as antithetical to 
>> the stated goals of the Swift evolution.
>> 
>> Regards, Michael
>> 
>> ==
>> Michael M. Mayer
>> Hanover, MD
>> m.may...@gmail.com
>> 
>> ___
>> 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] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[David Hart via swift-evolution]

> On 11 Apr 2017, at 08:48, Tino Heth via swift-evolution 
>  wrote:
> 
> -1 (strong)
> 
> I think I've read all messages and haven't much to add — so just to sum up my 
> concerns in order:
> — It makes access control more complicated
> For me, it's not about the complexity itself (it's not terrible huge, after 
> all), but I believe in the beauty of simplicity, which is already quite 
> flawed.
> — It adds no power to the language
> The proposal solves no real problem, but rather encourages a certain style of 
> programming, which is quite popular among authors of styleguides, but has no 
> clear net gain.

While your other points are defendable, I have to disagree here. It does bring 
value to a population of developers (me included) for whom that style of 
programming adds a lot of readability. It's part of style guides for a reason.

> — It diminishes the need for fileprivate without making it redundant
> It would be nice to get rid of an access level, but having four common ones 
> and fileprivate as an exotic outlier doesn't feel right for me.

Doesn't the argument of progressive disclosure sway you here? open is already 
an outlier that only library authors will play with, and that's a good thing. 
It reduces the number of access level truly useful on a day to day basis, while 
leaving the others for more narrow purposes.

> — It is a mockery for SE-0025
> I never liked "new private", but it was decided that this sort of 
> encapsulation is important enough to justify 33% increase in the number of 
> access levels, so I don't like to see this watered down
> — It is a breaking change
> For me personally, that doesn't really count as an argument on its own, and I 
> would gladly take the inconvenience of incompatibility in exchange for a tiny 
> improvement of the language; but in combination with the other points, it 
> increases opposition.
> 
> I spend some time thinking about nested extensions (which would achieve the 
> goal of this proposal naturally) and think that SE-0169 would lead to some 
> questionable possibilities of short-circuiting access control:
> 
> class Outer {
>   private class Inner {
>   private var x = 0
>   }
> }
> 
> /*
> .
> .
> .
> */
> 
> extension Outer.Inner {
>   public func f() {
>   print(x)
>   }
> }
> 
> As I read the proposal, there is no doubt that this would be allowed — but 
> without that detailed information, I'm not sure if anybody would expect that 
> two levels of private still is not enough to keep something secret…
> 
> - Tino
> ___
> 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] Enhancing access levels without breaking changes

[David Hart via swift-evolution]

> On 11 Apr 2017, at 09:40, John McCall  wrote:
> 
>> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>>  wrote:
>> 
>> Sent from my iPhone
>> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>>  wrote:
>> 
>>> I have not voted in favor or against the proposal. I have been reading a 
>>> lot of responses but I agree with Tony. 
>>> 
>>> When I started reading the proposal everything was more or less fine half 
>>> way through the proposal because it was reverting private to fileprivate 
>>> between the type and its extensions within the same file. I said, if you 
>>> think of the type and its extensions as a unit then it makes sense. I can 
>>> explain that. 
>>> 
>>> Then it started describing a different behavior among the extensions 
>>> located in a file separate from the file containing the definition of the 
>>> type. That just started a whole debate inside my head and I understand the 
>>> passionate responses on both sides. 
>>> 
>>> But then I imagined myself explaining this to someone new to Swift and it 
>>> just doesn't seem right. If it becomes convoluted then that's a red flag 
>>> that it does not belong in Swift. 
>> 
>> I understand what you are saying and I wouldn't be against relaxing that 
>> requirement (not talking for Chris here).
>> 
>> The model would change from "Types share scopes with their extensions in the 
>> same file the type was defined" to "Types and their extensions share the 
>> same scope in each file".
> 
> Oh, I had missed that somehow.  I agree that that is a very strange rule.  Do 
> you know why it was proposed that way?

We had to take a stance and Chris seemed to prefer the rule that was proposed. 
I didn't press because I'm sure he has reasons for preferring it that way. But 
I have a preference for generalizing visibility to all extensions, even to 
those in a different file than the type.

> John.
> 
>> 
>>> I agree fileprivate may be ugly to some and it may be more popular than 
>>> private. But I think fileprivate is very clear. I know what it does from 
>>> its name without having to ask. And private behaves the way private works 
>>> in other languages. 
>>> 
>>> Regards
>>> 
>>> 
 On Apr 10, 2017, at 1:35 PM, Tony Allevato via swift-evolution 
  wrote:
 
 
 
 On Mon, Apr 10, 2017 at 9:49 AM Tino Heth <2...@gmx.de> wrote:
>> But even outside the generated code use cases, it's nice to just be able 
>> to implement helpers or additional "convenience" conformances in 
>> separate files named appropriately (like "Type+Protocol.swift" or 
>> "Type+Helpers.swift"). I find it makes my codebase easier to navigate.
> 
> No doubt about the usefulness of having separate files with extensions 
> here
> 
>> If nothing else, nested extensions could save those who actually don't 
>> care much about such issues from another breaking change in Swift — and 
>> imho it adds consistency:
>> We can nest types, so why can't we nest extensions?
>> 
>> Because types and extensions are quite different beasts, so something 
>> that applies to one doesn't necessarily apply to the other.
> 
> I don't buy this argument at all without an objective explanation why the 
> curly braces of extensions should be treated different than the curly 
> braces of types...
 
 They shouldn't be. That's why I don't support SE-0169 either, because it 
 would allow extensions to extend the *scope* rather than the *type*, but 
 only within the same file. I think that's fundamentally broken.
 
 But my comment wasn't about curly braces—it was about types vs. 
 extensions. For example, you can declare local types within a function, 
 but you can't extend a type within a function (nor do I think it would be 
 a good idea).
 
  
> 
>> I don't think that holds its weight. This feels like another case of 
>> "let's try to satisfy everyone who's unhappy with some part of Swift 
>> visibility by changing a completely different feature to make things 
>> fall into place", which I don't think is a sound motivation or design 
>> principle. The example you posted in your initial message weaves 
>> multiple types/nesting levels together in a way that looks *incredibly* 
>> difficult to follow/parse to even an experienced user of the language.
> 
> Did you noticed that I started this example as mockery? In real life, I 
> would hopefully never nest more than once… and do you think sprinkling 
> parts of class over the project is easier to follow?
 
 Depending on the type, yes. I wouldn't sprinkle the *fundamental/core* 
 parts of a type across the project, but if there's some kind of "aside" 
 functionality that doesn't depend on private knowledge of the type, then I 
 find it to be a nice feature to have. It requires me to have reasonable 
 names to my source files, but that's

Re: [swift-evolution] Enhancing access levels without breaking changes

[John McCall via swift-evolution]

> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>  wrote:
> 
> Sent from my iPhone
> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> I have not voted in favor or against the proposal. I have been reading a lot 
>> of responses but I agree with Tony. 
>> 
>> When I started reading the proposal everything was more or less fine half 
>> way through the proposal because it was reverting private to fileprivate 
>> between the type and its extensions within the same file. I said, if you 
>> think of the type and its extensions as a unit then it makes sense. I can 
>> explain that. 
>> 
>> Then it started describing a different behavior among the extensions located 
>> in a file separate from the file containing the definition of the type. That 
>> just started a whole debate inside my head and I understand the passionate 
>> responses on both sides. 
>> 
>> But then I imagined myself explaining this to someone new to Swift and it 
>> just doesn't seem right. If it becomes convoluted then that's a red flag 
>> that it does not belong in Swift. 
> 
> I understand what you are saying and I wouldn't be against relaxing that 
> requirement (not talking for Chris here).
> 
> The model would change from "Types share scopes with their extensions in the 
> same file the type was defined" to "Types and their extensions share the same 
> scope in each file".

Oh, I had missed that somehow.  I agree that that is a very strange rule.  Do 
you know why it was proposed that way?

John.

> 
>> I agree fileprivate may be ugly to some and it may be more popular than 
>> private. But I think fileprivate is very clear. I know what it does from its 
>> name without having to ask. And private behaves the way private works in 
>> other languages. 
>> 
>> Regards
>> 
>> 
>> On Apr 10, 2017, at 1:35 PM, Tony Allevato via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
>>> 
>>> On Mon, Apr 10, 2017 at 9:49 AM Tino Heth <2...@gmx.de 
>>> > wrote:
 But even outside the generated code use cases, it's nice to just be able 
 to implement helpers or additional "convenience" conformances in separate 
 files named appropriately (like "Type+Protocol.swift" or 
 "Type+Helpers.swift"). I find it makes my codebase easier to navigate.
>>> 
>>> No doubt about the usefulness of having separate files with extensions here
>>> 
 If nothing else, nested extensions could save those who actually don't 
 care much about such issues from another breaking change in Swift — and 
 imho it adds consistency:
 We can nest types, so why can't we nest extensions?
 
 Because types and extensions are quite different beasts, so something that 
 applies to one doesn't necessarily apply to the other.
>>> 
>>> I don't buy this argument at all without an objective explanation why the 
>>> curly braces of extensions should be treated different than the curly 
>>> braces of types...
>>> 
>>> They shouldn't be. That's why I don't support SE-0169 either, because it 
>>> would allow extensions to extend the *scope* rather than the *type*, but 
>>> only within the same file. I think that's fundamentally broken.
>>> 
>>> But my comment wasn't about curly braces—it was about types vs. extensions. 
>>> For example, you can declare local types within a function, but you can't 
>>> extend a type within a function (nor do I think it would be a good idea).
>>> 
>>>  
>>> 
 I don't think that holds its weight. This feels like another case of 
 "let's try to satisfy everyone who's unhappy with some part of Swift 
 visibility by changing a completely different feature to make things fall 
 into place", which I don't think is a sound motivation or design 
 principle. The example you posted in your initial message weaves multiple 
 types/nesting levels together in a way that looks *incredibly* difficult 
 to follow/parse to even an experienced user of the language.
>>> 
>>> Did you noticed that I started this example as mockery? In real life, I 
>>> would hopefully never nest more than once… and do you think sprinkling 
>>> parts of class over the project is easier to follow?
>>> 
>>> Depending on the type, yes. I wouldn't sprinkle the *fundamental/core* 
>>> parts of a type across the project, but if there's some kind of "aside" 
>>> functionality that doesn't depend on private knowledge of the type, then I 
>>> find it to be a nice feature to have. It requires me to have reasonable 
>>> names to my source files, but that's not a significant burden.
>>> 
>>>  
>>> 
 Everyone seems to be striving for a "perfect" level of access control that 
 lets individual types/members dictate precisely what other types/members 
 can access them. I'm not sure if that perfection is attainable or not, but 
 even if it is, I don't think it's something we should strive for. I'd 
 rather have a simple

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Goffredo Marocchi via swift-evolution]

We currently pay a dear cost in compilation time for all the features Swift 
brings and this in itself harm productivity quite a bit, the gulf between Swift 
and Objective-C projects compile time wise is massive and right nowt seems like 
we are ignoring it sometimes. Type inference can be a non trivial component of 
that and while it is a wow factor feature initially, it has never been clear as 
a practical big win when code being self documenting and easy to debug and 
maintain is concerned... 

Sent from my iPhone

> On 11 Apr 2017, at 00:26, David Beck via swift-evolution 
>  wrote:
> 
> This seems like something a linter should handle.
> 
> > Hi all,
> > 
> > In a discussion about inferring parameter types from default value, Slava 
> > brought up some performance problems caused by type inference for stored 
> > properties in side types:
> > 
> > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> > 
> > Towards the end, the post mentioned that some Swift team members 
> > contemplated requiring types for stored properties in type declarations. I 
> > think this idea deserves some more attention. Hence this last minute 
> > idea-floating.
> > 
> > In addition to solving a performance headache in implementation, there're 
> > always the general benefit of making type declartion more explicit and 
> > readable (clarity for reader should out-weigh pleasure of the author). 
> > Making the
> > language slightly more consistent (we are not inferring types for default 
> > parameter values in function anyways).
> > 
> > The cons for doing this are obvious too: the inference makes the language 
> > feels more friendly and is, undoubtedly, a beloved feature for many. This 
> > would be a source breaking change.
> > 
> > Just thought I'd float the idea to gather some quick reaction. What do 
> > y'all think?
> > 
> > Daniel Duan
> > 
> > 
> >  
> 
> 
> David Beck
> http://davidbeck.co
> http://twitter.com/davbeck
> http://facebook.com/davbeck
> 
> ___
> 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] SE-0169

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 11 Apr 2017, at 02:41, Michael Mayer via swift-evolution 
>  wrote:
> 
> All -
> 
> I am not in favor of this change.  While I agree that the implementation of 
> fileprivate and open as well as the changes to private had some unintended 
> by-products, they can easily be accommodated.  Sometimes the language by its 
> nature dictates style.  I say at this point, we all just need to deal with it 
> and move on.  We have bigger and more impactful language features to fry.  
> 
> IMHO the changes in this proposal create a host of complications in the 
> understanding of what can already be a hard to understand topic.  We are 
> greatly increasing the surface area of what must be learned in order to 
> completely grok private and fileprivate.

The goal of progressive disclosure is NOT to reduce the amount of learning you 
need to get COMPLETE understanding of a topic like access control, but being 
able to get started easily with a small subset of info and go deeper if you 
need it and on your terms which this proposal achieves.

>  This added complexity does not justify what I feel are just cosmetic 
> improvements to suit a particular coding style.  
> 
> Changes such as this to suit a particular coding style, need to be avoided or 
> we risk losing focus on the definition and implementation of more critical 
> changes.
> 
> I don’t comment on many proposals, but this one stood out as antithetical to 
> the stated goals of the Swift evolution.
> 
> Regards, Michael
> 
> ==
> Michael M. Mayer
> Hanover, MD
> m.may...@gmail.com
> 
> ___
> 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