Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Martin R via swift-evolution]

Thank you for the response, but I have more questions. Will

Float(exactly: NSNumber(value: Double.pi))

fail because Float cannot represent the number Double.pi exactly? Or

Double(exactly: NSDecimalNumber(string: "1.9"))

because Double cannot represent the decimal fraction 1.9 exactly?

I find it difficult to evaluate the proposal without a description of the 
intended behavior of the "exact" conversions which covers all possible 
combinations (integers, floating point values, booleans). At present, the 
behavior is described only for stored integer types.

Regards, Martin

> On 14. Apr 2017, at 23:23, Philippe Hausler  wrote:
> 
>> 
>> On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution 
>> > wrote:
>> 
>> Apologies if I am overlooking something, but it seems to me that the 
>> proposal does not clearly define the behavior of the "exact" conversions 
>> between integer and floating point values. Does
>> 
>> Int(exactly: NSNumber(value: 12.34))
> 
> The exact value of a float or double constructed NSNumber will only happen 
> for integral values: e.g. 1.0, -32.0 etc
> 
>> 
>> fail because Int cannot represent the number exactly? Or are floating point 
>> values truncated silently and the conversion to an integer fails only if it 
>> overflows? And the other way around: Does
>> 
>> Double(exactly: NSNumber(value: Int64(901)))
>> 
>> fail because Double cannot represent the number exactly?
> 
> I believe this will fail because the Int64 value will exceed the mantissa 
> representation of the Double from my current implementation. 
> 
>> 
>> Regards, Martin
>> 
>>> On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution 
>>> > wrote:
>>> 
>>> Apologies, if you are reading this in HTML the links appear to be pointing 
>>> to the incorrect proposal. 
>>> 
>>> Here is the corrected link:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>>>  
>>> 
>>> 
 On Apr 14, 2017, at 11:30 AM, Ben Cohen > wrote:
 
 Hello Swift community,
 
 The review of “SE-0170: NSNumber bridging and Numeric types" begins now 
 and runs through the Friday after next, April 14th. The proposal is 
 available here:

 https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.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/0170-nsnumber_bridge.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,
 
 Ben Cohen
 Review Manager
 
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> 

[swift-evolution] Yet another access control pitch: Don't

[Maxim Veksler via swift-evolution]

I'd like to share with the group an approach to access control that I've
been thinking of, inspired by python philosophy.

What if we by default we don't have access control at all? Everything is
open to anyone. IMHO novice users will find it easier. Experienced users
will find that they need to type less. Enterprise / professional / security
& privacy concerns will be addressed by supporting a simplistic model
access control:

'all' - same as not specifying anything, meaning open.
'family' - accecible from within the given module.
'private' - accessible from definition scope, i.e "file".

*another name of "family" I can think of is "safe" because all files in the
module have mutual trust but it might lead people to think that without it
their code would somehow not be secure..

So basically I'm suggesting 2 things
1. Make public access be the default
2. Adopt a scope based simple model for access control of file, module,
world.

I think this covers most of the requirements of every day software needs,
based on my experience of writing backend code, core libraries code and iOS
code. Wearing both the had of library makers as well as consumer of 3rd
party code. Mostly this solves the issue of professional devs know to stick
to public API's because you know better, but at times when you do need to
access under the hook you're either locked out for now good reason or need
to do substantially complex hacks only because SDK / library couldn't
imagine your use case.

Final note, it's my personal opinion that the current access control in
swift is attempting to optimize for edge cases which is probably not the
best approach in what is positioned to be a general purpose language.

Would appreciate feedback.
Max.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Yet Another Access Control Pitch: Flexible Scoping

[Ben Langmuir via swift-evolution]

Hi Erica,

I think this proposal needs to address how allowing arbitrary identifiers to 
become declaration modifiers would work during parsing.  Custom accessgroups 
may not be in the same file - or even module - as the code they effect, meaning 
that

foo
bar
func myFunction() {}

cannot be parsed into anything reasonable until we’ve first found all of the 
visible accessgroup declarations.  It’s even worse when we do syntax-only 
parsing like we use for some IDE stuff (e.g. syntax colouring, code-folding). 
In that case we do not import any modules (not even the stdlib), and we are 
only looking at one file, not the full set of files in the module.

Ben

> On Apr 14, 2017, at 1:58 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Pull request: https://github.com/apple/swift-evolution/pull/681 
> 
> 
> Under the assumption that SE-0169 is adopted, Jeffrey B and I have been 
> brainstorming about what a follow-on might look like. We want to address 
> concerns that remain post-0169. Although this proposal is primarily additive, 
> we feel it might just squeak in under Swift 4's gate as it targets 
> potentially harmful language issues.
> 
> We appreciate your feedback about the substance of the proposal. At this 
> time, we're not looking for bikeshedding on design details. We will welcome 
> that once the question of whether the proposal is sufficiently substantive is 
> settled.  
> 
> Given the extremely limited timeline and the high volume of list traffic, 
> we're looking for specific concerns (or benefits) you see in this pitch 
> instead of a flurry of "+1" and "-1" responses . Our primary question regards 
> whether this is a suitable approach (it is strongly influenced by SE-0077) 
> and flexible enough to cover at least some outstanding concerns raised in 
> list threads over the past weeks.
> 
> Thank you in advance for your feedback,
> 
> -- Erica
> 
> ___
> 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]

This is all runtime processing. I think the indentation stripping is better 
done at compile time. 

You should be able to select the multi-line string constants in your array of 
stories example and indent them to look good in your code. Then just use the 
closing delimiter to tell the compiler how much indentation to strip. 

Here is Brent's excellent proposal in case you have not seen it:

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


> On Apr 14, 2017, at 11:12 PM, Muse M  wrote:
> 
> This would be prefer to follow Scala multiline string which look
> 
> 1) //Default 
> var code = """header
> paragraph1"""
> 
> Output:
> >header
> >paragraph1
> 
> 2)
> var code = """
> ...header...
> ...paragraph1...
> """.replace("...")
> 
> Output:
> >header
> >paragraph1
> 
> 3)
> var code = """
>  |..header...
>  |..paragraph1...
> """.stripLeadingSpace()
> 
> Output:
> >header...
> >paragraph1...
> 
> 4)
> var code = """
> 
> import Foundation
> print("Hello World!")
> 
> """.code()
> 
> Output:
> >
> >import Foundation
> >print("Hello World!")
> >
> 
> 5)
> //To remove all new lines
> var code = """
> import Foundation
> 
> import Cocoa
> 
> print("Hello World!")
> """.compactLine()
> 
> Output:
> >import Foundation
> >import Cocoa
> >print("Hello World!")
> 
> 
> 
> On Multiline String collection
> 
> 6) If we are importing many sources from 3rd parties API, we won't know if 
> their code is properly indent, some use tab and some use 2 or 4-space. This 
> would look better on Swift Playground app.
> 
> var stories = {
> """
> Chapter1
> 第1章
> 
> Introduction to A
> """,
> """
> Chapter2
> 第2章
> 
> Introduction to B
> """,
> """
> //Code Example
> import Foundation
> """
> }
> 
> We can loop or apply to certain collection
> stories(3).code()
> 
> 
> 
>> On Saturday, April 15, 2017, Ricardo Parada via swift-evolution 
>>  wrote:
>> I agree that it is not obvious. 
>> 
>> At one point I argued that the trailing newline on the last line should be 
>> stripped. But for this reason and others I am now in the camp that thinks we 
>> should leave the trailing newline alone. 
>> 
>> If we don't want to include the trailing newline we can always do this:
>> 
>> let str = """
>>Line 1
>>Line 2\
>>"""
>> 
>> This is were it's difficult to get consensus. 
>> 
>> Regards,
>> Ricardo 
>> 
>> 
>>> On Apr 14, 2017, at 5:54 PM, BJ Homer via swift-evolution 
>>>  wrote:
>>> 
>>> I’m not saying that the + operator should automatically add a newline. I’m 
>>> saying that both strings should contain a trailing newline, such that the 
>>> visible result is the same.
>>> 
>>> By contrast, this would feel really strange:
>>> 
>>> let a = """
>>> This is line one
>>> This is line two
>>> 
>>> """
>>> 
>>> let b = """
>>> This is line three
>>> This is line four
>>> """
>>> 
>>> (a + b) == """
>>> This is line one
>>> This is line two
>>> This is line three
>>> This is line four
>>> """
>>> 
>>> On initial intuition, it seems strange that ‘a’ has a blatantly visible 
>>> blank line at the end which seemingly “disappears” when the strings are 
>>> concatenated. If I think about it for a bit, I can understand why that 
>>> would be the case, but I think it’s non-obvious.
>>> 
>>> -BJ
>>> 
 On Apr 14, 2017, at 3:49 PM, Xiaodi Wu  wrote:
 
 I disagree. I expect the last result to be from `a + "\n" + b`, for the 
 reasons I outlined earlier.
 
 The concatenation operator + does not introduce implied separators when 
 joining strings. There is no reason to think that it should for multi-line 
 strings specifically.
> On Fri, Apr 14, 2017 at 16:35 BJ Homer via swift-evolution 
>  wrote:
> 
>> Consider these two examples:
>> 
>> let string_1 = """foo"""
>> 
>> 
>> let string_2 = """
>> foo
>> """
>> What’s the intuitive result you’d expect without taking all the long 
>> talk from the list into account?
>> 
>> Personally, I’d say string_1 == string_2 is true.
>> 
> 
> I think it’s reasonable to expect them to be different, actually. I might 
> call these “single-line” and “multi-line” mode strings. The single-line 
> mode is primarily useful for being able to include unescaped 
> double-quotes in the string. If you’re in multi-line mode, though, it’s 
> reasonable to be thinking about things in terms of “lines”, and having a 
> trailing newline there seems reasonable. For example, I think it’s 
> reasonable to expect this:
> 
> let a = """
> This is line one
> This is line two"
> """
> 
> let b = """
> This is line three
> This is line four
> """
> 
> (a + b) == """
> This is line one
> This is line two
> This is line three
> 

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

[Chris Lattner via swift-evolution]

> On Apr 12, 2017, at 6:09 AM, Ricardo Parada  wrote:
> 
> 
> On Apr 12, 2017, at 1:42 AM, Chris Lattner via swift-evolution 
> > 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
> 
> That would remove the objection I had. It would make the first half and the 
> second half of the proposal consistent. 

Just FYI, I revised the proposal.  It was an oversight/misunderstanding that 
the proposal indicated the previous approach:
https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

-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

[Muse M via swift-evolution]

This would be prefer to follow Scala multiline string which look

1) //Default
var code = """header
paragraph1"""

*Output:*
>header
>paragraph1

2)
var code = """
...header...
...paragraph1...
""".replace("...")

*Output:*
>header
>paragraph1

3)
var code = """
 |..header...
 |..paragraph1...
""".stripLeadingSpace()

*Output:*
>header...
>paragraph1...

4)
var code = """

import Foundation
print("Hello World!")

""".code()

*Output:*
>
>import Foundation
>print("Hello World!")
>

5)
//To remove all new lines
var code = """
import Foundation

import Cocoa

print("Hello World!")
""".compactLine()

*Output:*
>import Foundation
>import Cocoa
>print("Hello World!")



On Multiline String collection

6) If we are importing many sources from 3rd parties API, we won't know if
their code is properly indent, some use tab and some use 2 or 4-space. This
would look better on Swift Playground app.

var *stories* = {
"""
Chapter1
第1章

Introduction to A
""",
"""
Chapter2
第2章

Introduction to B
""",
"""
//Code Example
import Foundation
"""
}

We can loop or apply to certain collection
stories(3).code()



On Saturday, April 15, 2017, Ricardo Parada via swift-evolution <
swift-evolution@swift.org> wrote:

> I agree that it is not obvious.
>
> At one point I argued that the trailing newline on the last line should be
> stripped. But for this reason and others I am now in the camp that thinks
> we should leave the trailing newline alone.
>
> If we don't want to include the trailing newline we can always do this:
>
> let str = """
>Line 1
>Line 2\
>"""
>
> This is were it's difficult to get consensus.
>
> Regards,
> Ricardo
>
>
> On Apr 14, 2017, at 5:54 PM, BJ Homer via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’m not saying that the + operator should automatically add a newline. I’m
> saying that both strings should contain a trailing newline, such that the
> visible result is the same.
>
> By contrast, this would feel really strange:
>
> let a = """
> This is line one
> This is line two
>
>
> """
>
>
> let b = """
> This is line three
> This is line four
>
> """
>
>
> (a + b) == """
> This is line one
> This is line two
> This is line three
> This is line four
> """
>
>
> On initial intuition, it seems strange that ‘a’ has a blatantly visible
> blank line at the end which seemingly “disappears” when the strings are
> concatenated. If I think about it for a bit, I can understand why that
> would be the case, but I think it’s non-obvious.
>
> -BJ
>
> On Apr 14, 2017, at 3:49 PM, Xiaodi Wu  wrote:
>
> I disagree. I expect the last result to be from `a + "\n" + b`, for the
> reasons I outlined earlier.
>
> The concatenation operator + does not introduce implied separators when
> joining strings. There is no reason to think that it should for multi-line
> strings specifically.
> On Fri, Apr 14, 2017 at 16:35 BJ Homer via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> Consider these two examples:
>>
>> let string_1 = """foo"""
>>
>>
>> let string_2 = """
>> foo
>> """
>>
>> What’s the intuitive result you’d expect without taking all the long talk
>> from the list into account?
>>
>> Personally, I’d say string_1 == string_2 is true.
>>
>>
>> I think it’s reasonable to expect them to be different, actually. I might
>> call these “single-line” and “multi-line” mode strings. The single-line
>> mode is primarily useful for being able to include unescaped double-quotes
>> in the string. If you’re in multi-line mode, though, it’s reasonable to be
>> thinking about things in terms of “lines”, and having a trailing newline
>> there seems reasonable. For example, I think it’s reasonable to expect this:
>>
>> let a = """
>> This is line one
>> This is line two"
>> """
>>
>> let b = """
>> This is line three
>> This is line four
>> """
>>
>> (a + b) == """
>> This is line one
>> This is line two
>> This is line three
>> This is line four
>> """
>>
>>
>> That seems like a reasonable model to work with multi-line strings.
>>
>> -BJ
>> ___
>> 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] SE-0171: Reduce with inout

[T.J. Usiyan via swift-evolution]

+1 from me. I currently use reduce and just deal with the costs.

On Fri, Apr 14, 2017 at 10:15 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Apr 14, 2017, at 9:05 PM, David Sweeris  wrote:
> >
> >
> >> On Apr 14, 2017, at 15:33, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >>
> >>>   • What is your evaluation of the proposal?
> >>
> >> +0.5 because this is a half solution.  I would also like to see a
> variant which accepts an inout argument for the reduction to accumulate
> into.
> >
> > Out of curiosity, do you have any particular use case in mind, or do you
> just think that'd nicely "round out" the reduce functions (which would be
> fine with me).
>
> This would be useful in any use case that involves reducing data that
> isn’t all available at the same time for one reason or another (batches
> arrive periodically, data is processed in chunks to avoid loading
> everything into memory, etc).
>
> IMO the most fundamental variation of `reduce` Swift could offer is the
> one that takes and `inout` accumulator.  The others can easily be defined
> in terms of that.
>
> >
> > - Dave Sweeris
>
> ___
> 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-0171: Reduce with inout

[Matthew Johnson via swift-evolution]

> On Apr 14, 2017, at 9:05 PM, David Sweeris  wrote:
> 
> 
>> On Apr 14, 2017, at 15:33, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> 
>>>   • What is your evaluation of the proposal?
>> 
>> +0.5 because this is a half solution.  I would also like to see a variant 
>> which accepts an inout argument for the reduction to accumulate into.
> 
> Out of curiosity, do you have any particular use case in mind, or do you just 
> think that'd nicely "round out" the reduce functions (which would be fine 
> with me).

This would be useful in any use case that involves reducing data that isn’t all 
available at the same time for one reason or another (batches arrive 
periodically, data is processed in chunks to avoid loading everything into 
memory, etc).

IMO the most fundamental variation of `reduce` Swift could offer is the one 
that takes and `inout` accumulator.  The others can easily be defined in terms 
of that.

> 
> - Dave Sweeris

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

Re: [swift-evolution] SE-0171: Reduce with inout

[David Sweeris via swift-evolution]

> On Apr 14, 2017, at 15:33, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>>• What is your evaluation of the proposal?
> 
> +0.5 because this is a half solution.  I would also like to see a variant 
> which accepts an inout argument for the reduction to accumulate into.

Out of curiosity, do you have any particular use case in mind, or do you just 
think that'd nicely "round out" the reduce functions (which would be fine with 
me).

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

Re: [swift-evolution] Yet Another Access Control Pitch: Flexible Scoping

[Tony Arnold via swift-evolution]

Hi Erica,

> On 15 Apr 2017, at 08:44, Erica Sadun via swift-evolution 
>  wrote:
> 
> Like SE-0077's precedencegroup, this proposal is meant to mostly be invisible 
> to end-users. Most Swift users will never know anything changed from 
> S3/SE-0169 but it would support powerful use-cases for people who do serious 
> coding. 

I really like this proposal (Flexible Scoping). My one suggestion would be to 
make it clearer that for the average user, they just keep using the pre-defined 
access control levels as you’ve mentioned above.

I’m a little tired of seeing flexible access control referred to as an 
anti-goal — everyone has different requirements from this language, and this is 
the first time I’ve seen something that would potentially cover everybody’s 
needs without needlessly restricting things to meet one group’s idea of best 
practice. I’d ask that members of the community please consider that their 
ideas and needs are not everybody’s ideas and needs when assessing potentially 
contentious proposals like this one.

Personally, I’ve found the conversations around access control on this mailing 
list draining to the point I’ve unsubscribed from the list a few times. This is 
the first time I've felt like someone might be on the right track to solving 
this issue in a future-proof manner, and not just whacking a band-aid on the 
actual underlying issues.

Regardless of the outcome of discussions around this, thank you for the work 
that Jeffrey and yourself have put into it.

I'll +1 the heck out of this proposal if it gets to review.

thanks,


Tony




--
Tony Arnold
+61 411 268 532
http://thecocoabots.com/

ABN: 14831833541

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

Re: [swift-evolution] [swift-evolution-announce] SE-0171: Reduce with inout

[Ricardo Parada via swift-evolution]

> On Apr 14, 2017, at 2:37 PM, Ben Cohen  wrote:
> 
> Hello Swift community,
> 
> The review of “SE-0171: Reduce with inout" begins now and runs through the 
> Friday after next, April 14th. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md

>   • What is your evaluation of the proposal?

+1

>   • 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?

Yes

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

Quick read and read some of the responses. 


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

I agree that it is not obvious. 

At one point I argued that the trailing newline on the last line should be 
stripped. But for this reason and others I am now in the camp that thinks we 
should leave the trailing newline alone. 

If we don't want to include the trailing newline we can always do this:

let str = """
   Line 1
   Line 2\
   """

This is were it's difficult to get consensus. 

Regards,
Ricardo 


> On Apr 14, 2017, at 5:54 PM, BJ Homer via swift-evolution 
>  wrote:
> 
> I’m not saying that the + operator should automatically add a newline. I’m 
> saying that both strings should contain a trailing newline, such that the 
> visible result is the same.
> 
> By contrast, this would feel really strange:
> 
> let a = """
> This is line one
> This is line two
> 
> """
> 
> let b = """
> This is line three
> This is line four
> """
> 
> (a + b) == """
> This is line one
> This is line two
> This is line three
> This is line four
> """
> 
> On initial intuition, it seems strange that ‘a’ has a blatantly visible blank 
> line at the end which seemingly “disappears” when the strings are 
> concatenated. If I think about it for a bit, I can understand why that would 
> be the case, but I think it’s non-obvious.
> 
> -BJ
> 
>> On Apr 14, 2017, at 3:49 PM, Xiaodi Wu  wrote:
>> 
>> I disagree. I expect the last result to be from `a + "\n" + b`, for the 
>> reasons I outlined earlier.
>> 
>> The concatenation operator + does not introduce implied separators when 
>> joining strings. There is no reason to think that it should for multi-line 
>> strings specifically.
>>> On Fri, Apr 14, 2017 at 16:35 BJ Homer via swift-evolution 
>>>  wrote:
>>> 
 Consider these two examples:
 
 let string_1 = """foo"""
 
 
 let string_2 = """
 foo
 """
 What’s the intuitive result you’d expect without taking all the long talk 
 from the list into account?
 
 Personally, I’d say string_1 == string_2 is true.
 
>>> 
>>> I think it’s reasonable to expect them to be different, actually. I might 
>>> call these “single-line” and “multi-line” mode strings. The single-line 
>>> mode is primarily useful for being able to include unescaped double-quotes 
>>> in the string. If you’re in multi-line mode, though, it’s reasonable to be 
>>> thinking about things in terms of “lines”, and having a trailing newline 
>>> there seems reasonable. For example, I think it’s reasonable to expect this:
>>> 
>>> let a = """
>>> This is line one
>>> This is line two"
>>> """
>>> 
>>> let b = """
>>> This is line three
>>> This is line four
>>> """
>>> 
>>> (a + b) == """
>>> This is line one
>>> This is line two
>>> This is line three
>>> This is line four
>>> """
>>> 
>>> That seems like a reasonable model to work with multi-line strings.
>>> 
>>> -BJ
>>> ___
>>> 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] Yet Another Access Control Pitch: Flexible Scoping

[Erica Sadun via swift-evolution]

Like SE-0077's precedencegroup, this proposal is meant to mostly be invisible 
to end-users. Most Swift users will never know anything changed from S3/SE-0169 
but it would support powerful use-cases for people who do serious coding. 

-- E

> On Apr 14, 2017, at 4:02 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Agree with all of the above.
> 
> This document was an important one for someone to write. It represents a 
> complete design that no doubt is what some people aim for when they propose 
> incremental changes that add just one more access modifier, and one more, and 
> one more.
> 
> What is clear is that a good chunk of the community (in discussions about the 
> rollback of SE-0025) and the core team (and I do believe they have explicitly 
> talked about a design like this, though only in passing), believe the 
> motivations outlined here to be explicitly *anti*-goals for the language. 
> Only with the existence of this document can we have discuss this in a 
> concrete way.
> On Fri, Apr 14, 2017 at 16:51 David Waite via swift-evolution 
> > wrote:
> Afraid I have to agree - this proposal obviously had a lot of thought put 
> into it, but my opinion is that this level of complexity disguises the 
> purpose of access control.
> 
> The goal of access control (again IMHO) should be to support reduced coupling 
> and encapsulation. The goal is to both increase the ability to work within a 
> codebase without full knowledge of all of its code, and to allow evolution of 
> an implementation while knowing what API surface must remain stable to avoid 
> breaking dependent code.
> 
> So each access level needs to convey basically three things:
> - What am I supposed to understand before I start working on this code (e.g. 
> private = need to understand the workings of the type)
> - What is the impact if I change this code (e.g. internal = this may break 
> code within the current module, but shouldn’t affect the public ABI of the 
> model)
> - Is this considered an extension point for third parties to alter the 
> behavior of my type
> 
> I don’t think custom access levels help better convey what a developer should 
> know and what the impact of a change is.
> 
> -DW
> 
> 
>> On Apr 14, 2017, at 3:20 PM, Tony Allevato via swift-evolution 
>> > wrote:
>> 
>> I hate to be negative, since you've clearly put a lot of great thought into 
>> this. But ultimately, I feel that this is *significantly* more complicated 
>> than the problem of access control needs to be in Swift. I'm struggling to 
>> think of another programming language that supports this fine-grained level 
>> of detail.
>> 
>> The ability to create custom groups sounds like something that a very small 
>> minority of Swift writers would take advantage of. Meanwhile, it sounds like 
>> it would have the potential to greatly increase the learning curve of 
>> someone coming into a new code base, because now they have to potentially 
>> learn a whole new set of bespoke custom access modifiers that the authors 
>> decided to create.
>> 
>> I can only imagine that this would create a number of "dialects" of Swift, 
>> which the core team strongly wants to avoid (and which we should want to 
>> avoid as well). How would these access groups be namespaced? Are they 
>> restricted to only being usable within their module? (Meaning that they 
>> would effectively be erased when referencing a type/member with such groups 
>> outside that module?) If not, how do we guarantee that access groups are 
>> unique across code bases importing them from multiple modules? Regardless, 
>> this would allow two different Swift authors to create new custom access 
>> groups with the same name but completely different semantics.
>> 
>> The biggest problem, though, is that you can no longer look at a type/member 
>> in relative isolation and see where it's accessible from. "public", 
>> "internal", and so forth all have well-defined simple meanings. This change 
>> would mean that any time I look at a type/member with a custom access group, 
>> I have to go fishing for the group's declaration in order to understand who 
>> does and doesn't have access to it.
>> 
>> IMO, programmers simply do not need to finely tune and audit the visibility 
>> of their code to this level of detail. For public API boundaries, you should 
>> absolutely be able to control things. But once you're within a module or 
>> within a file—code that 99% of the time you as a developer or development 
>> team have complete control over—the value of being able to protect yourself 
>> from yourself or other teammates drops *significantly*. I argued this about 
>> scoped private as well, but the core team felt that it had legitimate enough 
>> use by a large enough number of people. On the other hand, I can't imagine 
>> that this would hold its weight 

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Matthew Johnson via swift-evolution]

> 
>   • What is your evaluation of the proposal?

+1.  I have run into problems with the current behavior a few times.  This 
proposal brings the behavior in-line with what I believe is best.

>   • 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?

Yes.  It continues the trend of refining the behavior of Objetive-C and Cocoa 
bridging.

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

I have not worked in a language with the kind of first-class bridging Swift has.

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

I was the author of SE-0080 and wanted to include similar provisions in that 
proposal early on so I think it’s fair to say an in-depth study.  I’m happy to 
see the Foundation side of this topic receiving attention.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0171: Reduce with inout

[Matthew Johnson via swift-evolution]

>   • What is your evaluation of the proposal?

+0.5 because this is a half solution.  I would also like to see a variant which 
accepts an inout argument for the reduction to accumulate into. 

>   • 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?

Yes.

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

N/A

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

Quick read and also followed earlier threads.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] SE-0171: Reduce with inout

[Howard Lovatt via swift-evolution]

>>> review of “SE-0171: Reduce with inout" 
>>> 
>>> • What is your evaluation of the proposal?

Good addition. Into is good name. 

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

Yes. I have written my own version. 

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

Yes. Improving collections worth while. 

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

The other liveries I have used with collect have had mutable versions. The 
Swift existing immutable version is the outlier for me. 

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

Quick read. 

-- Howard. 

> On 15 Apr 2017, at 4:41 am, Ben Cohen  wrote:
> 
> Apologies, if you are reading this in HTML the links appear to be pointing to 
> the incorrect proposal. 
> 
> Here is the corrected link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md
> 
>> On Apr 14, 2017, at 11:37 AM, Ben Cohen  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of “SE-0171: Reduce with inout" begins now and runs through the 
>> Friday after next, April 14th. The proposal is available here:
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.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/0171-reduce-with-inout.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,
>> 
>> Ben Cohen
>> Review Manager
>> 
>> 
>> ___
>> swift-evolution-announce mailing list
>> swift-evolution-annou...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> 
> ___
> 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

Re: [swift-evolution] Yet Another Access Control Pitch: Flexible Scoping

[Xiaodi Wu via swift-evolution]

Agree with all of the above.

This document was an important one for someone to write. It represents a
complete design that no doubt is what some people aim for when they propose
incremental changes that add just one more access modifier, and one more,
and one more.

What is clear is that a good chunk of the community (in discussions about
the rollback of SE-0025) and the core team (and I do believe they have
explicitly talked about a design like this, though only in passing),
believe the motivations outlined here to be explicitly *anti*-goals for the
language. Only with the existence of this document can we have discuss this
in a concrete way.
On Fri, Apr 14, 2017 at 16:51 David Waite via swift-evolution <
swift-evolution@swift.org> wrote:

> Afraid I have to agree - this proposal obviously had a lot of thought put
> into it, but my opinion is that this level of complexity disguises the
> purpose of access control.
>
> The goal of access control (again IMHO) should be to support reduced
> coupling and encapsulation. The goal is to both increase the ability to
> work within a codebase without full knowledge of all of its code, and to
> allow evolution of an implementation while knowing what API surface must
> remain stable to avoid breaking dependent code.
>
> So each access level needs to convey basically three things:
> - What am I supposed to understand before I start working on this code
> (e.g. private = need to understand the workings of the type)
> - What is the impact if I change this code (e.g. internal = this may break
> code within the current module, but shouldn’t affect the public ABI of the
> model)
> - Is this considered an extension point for third parties to alter the
> behavior of my type
>
> I don’t think custom access levels help better convey what a developer
> should know and what the impact of a change is.
>
> -DW
>
>
> On Apr 14, 2017, at 3:20 PM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I hate to be negative, since you've clearly put a lot of great thought
> into this. But ultimately, I feel that this is *significantly* more
> complicated than the problem of access control needs to be in Swift. I'm
> struggling to think of another programming language that supports this
> fine-grained level of detail.
>
> The ability to create custom groups sounds like something that a very
> small minority of Swift writers would take advantage of. Meanwhile, it
> sounds like it would have the potential to greatly increase the learning
> curve of someone coming into a new code base, because now they have to
> potentially learn a whole new set of bespoke custom access modifiers that
> the authors decided to create.
>
> I can only imagine that this would create a number of "dialects" of Swift,
> which the core team strongly wants to avoid (and which we should want to
> avoid as well). How would these access groups be namespaced? Are they
> restricted to only being usable within their module? (Meaning that they
> would effectively be erased when referencing a type/member with such groups
> outside that module?) If not, how do we guarantee that access groups are
> unique across code bases importing them from multiple modules? Regardless,
> this would allow two different Swift authors to create new custom access
> groups with the same name but completely different semantics.
>
> The biggest problem, though, is that you can no longer look at a
> type/member in relative isolation and see where it's accessible from.
> "public", "internal", and so forth all have well-defined simple meanings.
> This change would mean that any time I look at a type/member with a custom
> access group, I have to go fishing for the group's declaration in order to
> understand who does and doesn't have access to it.
>
> IMO, programmers simply do not need to finely tune and audit the
> visibility of their code to this level of detail. For public API
> boundaries, you should absolutely be able to control things. But once
> you're within a module or within a file—code that 99% of the time you as a
> developer or development team have complete control over—the value of being
> able to protect yourself from yourself or other teammates drops
> *significantly*. I argued this about scoped private as well, but the core
> team felt that it had legitimate enough use by a large enough number of
> people. On the other hand, I can't imagine that this would hold its weight
> in terms of value-added vs. implementation complexity and difficulty it
> would add to making the language readable and learnable.
>
> On Fri, Apr 14, 2017 at 2:01 PM Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Pull request: https://github.com/apple/swift-evolution/pull/681
>>
>> Under the assumption that SE-0169 is adopted, Jeffrey B and I have been
>> brainstorming about what a follow-on might look like. We want to address
>> concerns that remain post-0169. Although this proposal is primarily
>> 

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

[BJ Homer via swift-evolution]

I’m not saying that the + operator should automatically add a newline. I’m 
saying that both strings should contain a trailing newline, such that the 
visible result is the same.

By contrast, this would feel really strange:

let a = """
This is line one
This is line two

"""

let b = """
This is line three
This is line four
"""

(a + b) == """
This is line one
This is line two
This is line three
This is line four
"""

On initial intuition, it seems strange that ‘a’ has a blatantly visible blank 
line at the end which seemingly “disappears” when the strings are concatenated. 
If I think about it for a bit, I can understand why that would be the case, but 
I think it’s non-obvious.

-BJ

> On Apr 14, 2017, at 3:49 PM, Xiaodi Wu  wrote:
> 
> I disagree. I expect the last result to be from `a + "\n" + b`, for the 
> reasons I outlined earlier.
> 
> The concatenation operator + does not introduce implied separators when 
> joining strings. There is no reason to think that it should for multi-line 
> strings specifically.
> On Fri, Apr 14, 2017 at 16:35 BJ Homer via swift-evolution 
> > wrote:
> 
>> Consider these two examples:
>> 
>> let string_1 = """foo"""
>> 
>> 
>> let string_2 = """
>> foo
>> """
>> What’s the intuitive result you’d expect without taking all the long talk 
>> from the list into account?
>> 
>> Personally, I’d say string_1 == string_2 is true.
>> 
> 
> I think it’s reasonable to expect them to be different, actually. I might 
> call these “single-line” and “multi-line” mode strings. The single-line mode 
> is primarily useful for being able to include unescaped double-quotes in the 
> string. If you’re in multi-line mode, though, it’s reasonable to be thinking 
> about things in terms of “lines”, and having a trailing newline there seems 
> reasonable. For example, I think it’s reasonable to expect this:
> 
> let a = """
> This is line one
> This is line two"
> """
> 
> let b = """
> This is line three
> This is line four
> """
> 
> (a + b) == """
> This is line one
> This is line two
> This is line three
> This is line four
> """
> 
> That seems like a reasonable model to work with multi-line strings.
> 
> -BJ
> ___
> 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] Yet Another Access Control Pitch: Flexible Scoping

[David Waite via swift-evolution]

Afraid I have to agree - this proposal obviously had a lot of thought put into 
it, but my opinion is that this level of complexity disguises the purpose of 
access control.

The goal of access control (again IMHO) should be to support reduced coupling 
and encapsulation. The goal is to both increase the ability to work within a 
codebase without full knowledge of all of its code, and to allow evolution of 
an implementation while knowing what API surface must remain stable to avoid 
breaking dependent code.

So each access level needs to convey basically three things:
- What am I supposed to understand before I start working on this code (e.g. 
private = need to understand the workings of the type)
- What is the impact if I change this code (e.g. internal = this may break code 
within the current module, but shouldn’t affect the public ABI of the model)
- Is this considered an extension point for third parties to alter the behavior 
of my type

I don’t think custom access levels help better convey what a developer should 
know and what the impact of a change is.

-DW


> On Apr 14, 2017, at 3:20 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> I hate to be negative, since you've clearly put a lot of great thought into 
> this. But ultimately, I feel that this is *significantly* more complicated 
> than the problem of access control needs to be in Swift. I'm struggling to 
> think of another programming language that supports this fine-grained level 
> of detail.
> 
> The ability to create custom groups sounds like something that a very small 
> minority of Swift writers would take advantage of. Meanwhile, it sounds like 
> it would have the potential to greatly increase the learning curve of someone 
> coming into a new code base, because now they have to potentially learn a 
> whole new set of bespoke custom access modifiers that the authors decided to 
> create.
> 
> I can only imagine that this would create a number of "dialects" of Swift, 
> which the core team strongly wants to avoid (and which we should want to 
> avoid as well). How would these access groups be namespaced? Are they 
> restricted to only being usable within their module? (Meaning that they would 
> effectively be erased when referencing a type/member with such groups outside 
> that module?) If not, how do we guarantee that access groups are unique 
> across code bases importing them from multiple modules? Regardless, this 
> would allow two different Swift authors to create new custom access groups 
> with the same name but completely different semantics.
> 
> The biggest problem, though, is that you can no longer look at a type/member 
> in relative isolation and see where it's accessible from. "public", 
> "internal", and so forth all have well-defined simple meanings. This change 
> would mean that any time I look at a type/member with a custom access group, 
> I have to go fishing for the group's declaration in order to understand who 
> does and doesn't have access to it.
> 
> IMO, programmers simply do not need to finely tune and audit the visibility 
> of their code to this level of detail. For public API boundaries, you should 
> absolutely be able to control things. But once you're within a module or 
> within a file—code that 99% of the time you as a developer or development 
> team have complete control over—the value of being able to protect yourself 
> from yourself or other teammates drops *significantly*. I argued this about 
> scoped private as well, but the core team felt that it had legitimate enough 
> use by a large enough number of people. On the other hand, I can't imagine 
> that this would hold its weight in terms of value-added vs. implementation 
> complexity and difficulty it would add to making the language readable and 
> learnable.
> 
> On Fri, Apr 14, 2017 at 2:01 PM Erica Sadun via swift-evolution 
> > wrote:
> Pull request: https://github.com/apple/swift-evolution/pull/681 
> 
> 
> Under the assumption that SE-0169 is adopted, Jeffrey B and I have been 
> brainstorming about what a follow-on might look like. We want to address 
> concerns that remain post-0169. Although this proposal is primarily additive, 
> we feel it might just squeak in under Swift 4's gate as it targets 
> potentially harmful language issues.
> 
> We appreciate your feedback about the substance of the proposal. At this 
> time, we're not looking for bikeshedding on design details. We will welcome 
> that once the question of whether the proposal is sufficiently substantive is 
> settled.  
> 
> Given the extremely limited timeline and the high volume of list traffic, 
> we're looking for specific concerns (or benefits) you see in this pitch 
> instead of a flurry of "+1" and "-1" responses . Our primary question regards 
> whether this is a suitable approach (it is strongly influenced 

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

[Xiaodi Wu via swift-evolution]

I disagree. I expect the last result to be from `a + "\n" + b`, for the
reasons I outlined earlier.

The concatenation operator + does not introduce implied separators when
joining strings. There is no reason to think that it should for multi-line
strings specifically.
On Fri, Apr 14, 2017 at 16:35 BJ Homer via swift-evolution <
swift-evolution@swift.org> wrote:

> Consider these two examples:
>
> let string_1 = """foo"""
>
>
> let string_2 = """
> foo
> """
>
> What’s the intuitive result you’d expect without taking all the long talk
> from the list into account?
>
> Personally, I’d say string_1 == string_2 is true.
>
>
> I think it’s reasonable to expect them to be different, actually. I might
> call these “single-line” and “multi-line” mode strings. The single-line
> mode is primarily useful for being able to include unescaped double-quotes
> in the string. If you’re in multi-line mode, though, it’s reasonable to be
> thinking about things in terms of “lines”, and having a trailing newline
> there seems reasonable. For example, I think it’s reasonable to expect this:
>
> let a = """
> This is line one
> This is line two"
> """
>
> let b = """
> This is line three
> This is line four
> """
>
> (a + b) == """
> This is line one
> This is line two
> This is line three
> This is line four
> """
>
>
> That seems like a reasonable model to work with multi-line strings.
>
> -BJ
> ___
> 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-0171: Reduce with inout

[Guillaume Lessard via swift-evolution]

> https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md
> 
> • What is your evaluation of the proposal?

I support this proposal. It is easy to inadvertently write inefficient 
algorithms with reduce, and this provides a built-in solution. The parameter 
label is decent, and it differentiates the overloads nicely; that helps with 
readability. I think that the straight overload case becomes less readable; 
that happens to reinforce the compiler performance concern.


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

Yes. A lot of transformations can be implemented on top of ‘reduce’; this will 
help a class of those solutions be more efficient.

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

Yes. A functional algorithm that embraces mutation in the name of efficiency: 
so swifty.

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

Participated in discussion, experimented with the concept.

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

[BJ Homer via swift-evolution]

> Consider these two examples:
> 
> let string_1 = """foo"""
> 
> 
> let string_2 = """
> foo
> """
> What’s the intuitive result you’d expect without taking all the long talk 
> from the list into account?
> 
> Personally, I’d say string_1 == string_2 is true.
> 

I think it’s reasonable to expect them to be different, actually. I might call 
these “single-line” and “multi-line” mode strings. The single-line mode is 
primarily useful for being able to include unescaped double-quotes in the 
string. If you’re in multi-line mode, though, it’s reasonable to be thinking 
about things in terms of “lines”, and having a trailing newline there seems 
reasonable. For example, I think it’s reasonable to expect this:

let a = """
This is line one
This is line two"
"""

let b = """
This is line three
This is line four
"""

(a + b) == """
This is line one
This is line two
This is line three
This is line four
"""

That seems like a reasonable model to work with multi-line strings.

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

Re: [swift-evolution] Yet Another Access Control Pitch: Flexible Scoping

[David Hart via swift-evolution]

Tony resumed very well my thought on this proposal. I'd like to add that even 
with all its complexity, it does not solve any of the issues introduced with 
SE-0025 and that the recent proposals have tried to fix. At the heart, SE-0159 
and SE-0169 try to bring back a good safe-default private modifier. This 
proposal does not do that and a custom access level can never be a "default".

> On 14 Apr 2017, at 23:20, Tony Allevato via swift-evolution 
>  wrote:
> 
> I hate to be negative, since you've clearly put a lot of great thought into 
> this. But ultimately, I feel that this is *significantly* more complicated 
> than the problem of access control needs to be in Swift. I'm struggling to 
> think of another programming language that supports this fine-grained level 
> of detail.
> 
> The ability to create custom groups sounds like something that a very small 
> minority of Swift writers would take advantage of. Meanwhile, it sounds like 
> it would have the potential to greatly increase the learning curve of someone 
> coming into a new code base, because now they have to potentially learn a 
> whole new set of bespoke custom access modifiers that the authors decided to 
> create.
> 
> I can only imagine that this would create a number of "dialects" of Swift, 
> which the core team strongly wants to avoid (and which we should want to 
> avoid as well). How would these access groups be namespaced? Are they 
> restricted to only being usable within their module? (Meaning that they would 
> effectively be erased when referencing a type/member with such groups outside 
> that module?) If not, how do we guarantee that access groups are unique 
> across code bases importing them from multiple modules? Regardless, this 
> would allow two different Swift authors to create new custom access groups 
> with the same name but completely different semantics.
> 
> The biggest problem, though, is that you can no longer look at a type/member 
> in relative isolation and see where it's accessible from. "public", 
> "internal", and so forth all have well-defined simple meanings. This change 
> would mean that any time I look at a type/member with a custom access group, 
> I have to go fishing for the group's declaration in order to understand who 
> does and doesn't have access to it.
> 
> IMO, programmers simply do not need to finely tune and audit the visibility 
> of their code to this level of detail. For public API boundaries, you should 
> absolutely be able to control things. But once you're within a module or 
> within a file—code that 99% of the time you as a developer or development 
> team have complete control over—the value of being able to protect yourself 
> from yourself or other teammates drops *significantly*. I argued this about 
> scoped private as well, but the core team felt that it had legitimate enough 
> use by a large enough number of people. On the other hand, I can't imagine 
> that this would hold its weight in terms of value-added vs. implementation 
> complexity and difficulty it would add to making the language readable and 
> learnable.
> 
>> On Fri, Apr 14, 2017 at 2:01 PM Erica Sadun via swift-evolution 
>>  wrote:
>> Pull request: https://github.com/apple/swift-evolution/pull/681
>> 
>> Under the assumption that SE-0169 is adopted, Jeffrey B and I have been 
>> brainstorming about what a follow-on might look like. We want to address 
>> concerns that remain post-0169. Although this proposal is primarily 
>> additive, we feel it might just squeak in under Swift 4's gate as it targets 
>> potentially harmful language issues.
>> 
>> We appreciate your feedback about the substance of the proposal. At this 
>> time, we're not looking for bikeshedding on design details. We will welcome 
>> that once the question of whether the proposal is sufficiently substantive 
>> is settled.  
>> 
>> Given the extremely limited timeline and the high volume of list traffic, 
>> we're looking for specific concerns (or benefits) you see in this pitch 
>> instead of a flurry of "+1" and "-1" responses . Our primary question 
>> regards whether this is a suitable approach (it is strongly influenced by 
>> SE-0077) and flexible enough to cover at least some outstanding concerns 
>> raised in list threads over the past weeks.
>> 
>> Thank you in advance for your feedback,
>> 
>> -- Erica
>> 
>> ___
>> 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] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

> On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution 
>  wrote:
> 
> Apologies if I am overlooking something, but it seems to me that the proposal 
> does not clearly define the behavior of the "exact" conversions between 
> integer and floating point values. Does
> 
> Int(exactly: NSNumber(value: 12.34))

The exact value of a float or double constructed NSNumber will only happen for 
integral values: e.g. 1.0, -32.0 etc

> 
> fail because Int cannot represent the number exactly? Or are floating point 
> values truncated silently and the conversion to an integer fails only if it 
> overflows? And the other way around: Does
> 
> Double(exactly: NSNumber(value: Int64(901)))
> 
> fail because Double cannot represent the number exactly?

I believe this will fail because the Int64 value will exceed the mantissa 
representation of the Double from my current implementation. 

> 
> Regards, Martin
> 
>> On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution 
>> > wrote:
>> 
>> Apologies, if you are reading this in HTML the links appear to be pointing 
>> to the incorrect proposal. 
>> 
>> Here is the corrected link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>>  
>> 
>> 
>>> On Apr 14, 2017, at 11:30 AM, Ben Cohen >> > wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of “SE-0170: NSNumber bridging and Numeric types" begins now and 
>>> runs through the Friday after next, April 14th. The proposal is available 
>>> here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.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/0170-nsnumber_bridge.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,
>>> 
>>> Ben Cohen
>>> Review Manager
>>> 
>>> 
>> 
>> ___
>> 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] Yet Another Access Control Pitch: Flexible Scoping

[Tony Allevato via swift-evolution]

I hate to be negative, since you've clearly put a lot of great thought into
this. But ultimately, I feel that this is *significantly* more complicated
than the problem of access control needs to be in Swift. I'm struggling to
think of another programming language that supports this fine-grained level
of detail.

The ability to create custom groups sounds like something that a very small
minority of Swift writers would take advantage of. Meanwhile, it sounds
like it would have the potential to greatly increase the learning curve of
someone coming into a new code base, because now they have to potentially
learn a whole new set of bespoke custom access modifiers that the authors
decided to create.

I can only imagine that this would create a number of "dialects" of Swift,
which the core team strongly wants to avoid (and which we should want to
avoid as well). How would these access groups be namespaced? Are they
restricted to only being usable within their module? (Meaning that they
would effectively be erased when referencing a type/member with such groups
outside that module?) If not, how do we guarantee that access groups are
unique across code bases importing them from multiple modules? Regardless,
this would allow two different Swift authors to create new custom access
groups with the same name but completely different semantics.

The biggest problem, though, is that you can no longer look at a
type/member in relative isolation and see where it's accessible from.
"public", "internal", and so forth all have well-defined simple meanings.
This change would mean that any time I look at a type/member with a custom
access group, I have to go fishing for the group's declaration in order to
understand who does and doesn't have access to it.

IMO, programmers simply do not need to finely tune and audit the visibility
of their code to this level of detail. For public API boundaries, you
should absolutely be able to control things. But once you're within a
module or within a file—code that 99% of the time you as a developer or
development team have complete control over—the value of being able to
protect yourself from yourself or other teammates drops *significantly*. I
argued this about scoped private as well, but the core team felt that it
had legitimate enough use by a large enough number of people. On the other
hand, I can't imagine that this would hold its weight in terms of
value-added vs. implementation complexity and difficulty it would add to
making the language readable and learnable.

On Fri, Apr 14, 2017 at 2:01 PM Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> Pull request: https://github.com/apple/swift-evolution/pull/681
>
> Under the assumption that SE-0169 is adopted, Jeffrey B and I have been
> brainstorming about what a follow-on might look like. We want to address
> concerns that remain post-0169. Although this proposal is primarily
> additive, we feel it might just squeak in under Swift 4's gate as it
> targets potentially harmful language issues.
>
> We appreciate your feedback about the substance of the proposal. At this
> time, we're not looking for bikeshedding on design details. We will welcome
> that once the question of whether the proposal is sufficiently substantive
> is settled.
>
> Given the extremely limited timeline and the high volume of list traffic,
> we're looking for specific concerns (or benefits) you see in this pitch
> instead of a flurry of "+1" and "-1" responses . Our primary question
> regards whether this is a suitable approach (it is strongly influenced by
> SE-0077) and flexible enough to cover at least some outstanding concerns
> raised in list threads over the past weeks.
>
> Thank you in advance for your feedback,
>
> -- Erica
>
> ___
> 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-0170: NSNumber bridging and Numeric types

[Martin R via swift-evolution]

Apologies if I am overlooking something, but it seems to me that the proposal 
does not clearly define the behavior of the "exact" conversions between integer 
and floating point values. Does

Int(exactly: NSNumber(value: 12.34))

fail because Int cannot represent the number exactly? Or are floating point 
values truncated silently and the conversion to an integer fails only if it 
overflows? And the other way around: Does

Double(exactly: NSNumber(value: Int64(901)))

fail because Double cannot represent the number exactly?

Regards, Martin

> On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution 
>  wrote:
> 
> Apologies, if you are reading this in HTML the links appear to be pointing to 
> the incorrect proposal. 
> 
> Here is the corrected link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>  
> 
> 
>> On Apr 14, 2017, at 11:30 AM, Ben Cohen > > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of “SE-0170: NSNumber bridging and Numeric types" begins now and 
>> runs through the Friday after next, April 14th. The proposal is available 
>> here:
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.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/0170-nsnumber_bridge.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,
>> 
>> Ben Cohen
>> Review Manager
>> 
>> 
> 
> ___
> 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-0171: Reduce with inout

[BJ Homer via swift-evolution]

Ah, that makes sense. I was forgetting that the parameter label was on the 
initial value. 

+1 from me!

-BJ

> On Apr 14, 2017, at 3:07 PM, Guillaume Lessard via swift-evolution 
>  wrote:
> 
> The mutating version would have a parameter label to differentiate it:
> 
> let a = [1, 2, 3, 4, 5]
> 
> let b = a.reduce(into: []) { (result, element) in
>result.append(element * 2)
> }
> 
> --
> GL
> 
> ___
> 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-0171: Reduce with inout

[Guillaume Lessard via swift-evolution]

The mutating version would have a parameter label to differentiate it:

let a = [1, 2, 3, 4, 5]

let b = a.reduce(into: []) { (result, element) in
result.append(element * 2)
}

--
GL

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

[swift-evolution] Yet Another Access Control Pitch: Flexible Scoping

[Erica Sadun via swift-evolution]

Pull request: https://github.com/apple/swift-evolution/pull/681 


Under the assumption that SE-0169 is adopted, Jeffrey B and I have been 
brainstorming about what a follow-on might look like. We want to address 
concerns that remain post-0169. Although this proposal is primarily additive, 
we feel it might just squeak in under Swift 4's gate as it targets potentially 
harmful language issues.

We appreciate your feedback about the substance of the proposal. At this time, 
we're not looking for bikeshedding on design details. We will welcome that once 
the question of whether the proposal is sufficiently substantive is settled.  

Given the extremely limited timeline and the high volume of list traffic, we're 
looking for specific concerns (or benefits) you see in this pitch instead of a 
flurry of "+1" and "-1" responses . Our primary question regards whether this 
is a suitable approach (it is strongly influenced by SE-0077) and flexible 
enough to cover at least some outstanding concerns raised in list threads over 
the past weeks.

Thank you in advance for your feedback,

-- Erica

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

Re: [swift-evolution] SE-0171: Reduce with inout

[BJ Homer via swift-evolution]

Does inference still work correctly when trailing closure syntax is used, if 
the arguments are not given types?

For example, here’s some code that works in Swift right now:

let a = [1, 2, 3, 4, 5]
let b = a.reduce([]) { (result, element) in
return result + [element * 2]
}

Under the new proposal, this code would also be valid:

let a = [1, 2, 3, 4, 5]

let b = a.reduce([]) { (result, element) in
result.append(element * 2)
}
Note that these both of these closures appear to have the same signature: two 
parameters of inferred type, and an inferred return type. The “inout” and 
return types differ, but neither are specified here. Will the compiler be able 
to correctly infer the types based on the presence or absence of a “return” 
statement in the closure body? If not, it seems like the first example will 
become ambiguous.

-BJ


> On Apr 14, 2017, at 12:37 PM, Ben Cohen via swift-evolution 
> > wrote:
> 
> Hello Swift community,
> 
> The review of “SE-0171: Reduce with inout" begins now and runs through the 
> Friday after next, April 14th. The proposal is available here:
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.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/0171-reduce-with-inout.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,
> 
> Ben Cohen
> Review Manager
> 
> 
> ___
> 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] SE-0171: Reduce with inout

[Charles Srstka via swift-evolution]

Yes, please. This will fill a major hole; namely, allowing us to populate 
collections functionally when the problem is too complex for a simple ‘map’ 
operation, or when the collection being built is something other than an array.

Charles

> On Apr 14, 2017, at 1:41 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> Apologies, if you are reading this in HTML the links appear to be pointing to 
> the incorrect proposal. 
> 
> Here is the corrected link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md
>  
> 
>> On Apr 14, 2017, at 11:37 AM, Ben Cohen > > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of “SE-0171: Reduce with inout" begins now and runs through the 
>> Friday after next, April 14th. The proposal is available here:
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.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/0171-reduce-with-inout.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,
>> 
>> Ben Cohen
>> 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

Re: [swift-evolution] SE-0171: Reduce with inout

[David Hart via swift-evolution]

>   • What is your evaluation of the proposal?

Great addition. Reduce (aka foldl) is so useful and universal that a proposal 
like this that increases its usefulness is a big +1 for me.

>   • 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?

It does fit with Swift’s direction to bring functional paradigms but also 
provide good performance.

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

No.

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

Followed the original discussion.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Ben Cohen via swift-evolution]

Apologies, if you are reading this in HTML the links appear to be pointing to 
the incorrect proposal. 

Here is the corrected link:

https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md

> On Apr 14, 2017, at 11:30 AM, Ben Cohen  wrote:
> 
> Hello Swift community,
> 
> The review of “SE-0170: NSNumber bridging and Numeric types" begins now and 
> runs through the Friday after next, April 14th. The proposal is available 
> here:
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.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/0170-nsnumber_bridge.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,
> 
> Ben Cohen
> Review Manager
> 
> 

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

Re: [swift-evolution] [swift-evolution-announce] SE-0171: Reduce with inout

[Ben Cohen via swift-evolution]

Apologies, if you are reading this in HTML the links appear to be pointing to 
the incorrect proposal. 

Here is the corrected link:

https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md

> On Apr 14, 2017, at 11:37 AM, Ben Cohen  wrote:
> 
> Hello Swift community,
> 
> The review of “SE-0171: Reduce with inout" begins now and runs through the 
> Friday after next, April 14th. The proposal is available here:
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.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/0171-reduce-with-inout.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,
> 
> Ben Cohen
> 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] SE-0171: Reduce with inout

[Ben Cohen via swift-evolution]

Hello Swift community,

The review of “SE-0171: Reduce with inout" begins now and runs through the 
Friday after next, April 14th. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.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/0171-reduce-with-inout.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,

Ben Cohen
Review Manager


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

[swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Ben Cohen via swift-evolution]

Hello Swift community,

The review of “SE-0170: NSNumber bridging and Numeric types" begins now and 
runs through the Friday after next, April 14th. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.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/0170-nsnumber_bridge.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,

Ben Cohen
Review Manager


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

Re: [swift-evolution] [Proposal] Nested extensions

[Tino Heth via swift-evolution]

> As I've mentioned three or four times already on this list, every time this 
> issue is brought up, the rules of access modifiers as revised in SE-0025 
> *cannot accommodate* non-top level extensions.
Sorry to bother you, but do you have a string to search for, or can forward a 
mail that's part of of one of those threads that haven't been allowed to be 
reviewed?
Afair, there even was a review for a proposal that wanted to fully revert 
SE-0025, so I wonder why it should be forbidden to question parts of it?___
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]

Hi Thorsten,

I think we’ve found a lightweight alternative solution for that problem. If you 
add trailing whitespace characters but no backslash the compiler will emit a 
warning. Depending which line produced the warning, a Fix-it will either add 
\n\ or a single \ after the last whitespace character in that line. This will 
kind of force the developer to be precise about whitespaces.

You’ll have two options:

Remove unneeded whitespaces.
Add \n\ or \ for precision.


-- 
Adrian Zubarev
Sent with Airmail

Am 14. April 2017 um 19:19:47, Thorsten Seitz (tseit...@icloud.com) schrieb:

I agree with Adrian that trailing whitespace which is not followed by a 
backslash should be stripped, because it is not visible otherwise (unlike in a 
normal string).

-Thorsten


Am 13.04.2017 um 15:32 schrieb Adrian Zubarev via swift-evolution 
:

Theoretically that would be enough and lightweight solution to that problem, I 
could live with that. Optimally stripping them automatically would be ideal, 
however I cannot tell how complicated this might be to implement.

A warning that will popup when you included any trailing spaces in a ‘content 
line’ without the explicit backslash could also provide a fix-it to the user to 
remove these spaces. However if you can emit that warning and calculate the 
spaces to remove, than the compiler should be able to swallow these characters 
by default right?

let s1 = """↵
content·⇥···⇥··⇥↵


s1 == "content" // => true
The warning itself could bite with Xcode, it depends on who’s faster to precede 
that problem. Either Xcode will strip them for you (but designing the literal 
we should not rely on that), or the compiler will emit the warning followed by 
Xcode which will strip them, which removes the warning. This would be kind of 
silly right?




-- 
Adrian Zubarev
Sent with Airmail

Am 13. April 2017 um 15:10:36, John Holdsworth (m...@johnholdsworth.com) 
schrieb:

Hi Adrian,

Would you settle for a warning for trailing whitespace in a literal?
Removing it is a bit fiddly to implement and I’m not sure it’s a feature.

John


On 13 Apr 2017, at 14:05, Adrian Zubarev via swift-evolution 
 wrote:

That would be so wrong, because it’s not obvious to anyone how long your string 
will be.

"""
foo
"""
I could tell you, that the string from above could have 10k characters, even if 
you wouldn’t believe me, as it was proposed (and included in yesterday’s 
toolchain) my claim can be true.

The trailing spaces needs to be stripped by the algorithm unless there is an 
explicit precision annotation with a backslash!

"""
foo   \
"""
That example definitely won’t have 10k characters.




-- 
Adrian Zubarev
Sent with Airmail

Am 13. April 2017 um 14:35:59, Ricardo Parada (rpar...@mac.com) schrieb:

Trailing whitespace 

You also propose to remove trailing white space in each line unless the 
whitespace is followed by a backslash.   For example:
let str_2 = """↵ 
foo··↵
"""
The two trailing whitespaces after foo would get removed according to what you 
are proposing. I don't like this rule. I think we are better off with leaving 
it alone and to the tools as Brent suggested. 

___
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

[Thorsten Seitz via swift-evolution]

I agree with Adrian that trailing whitespace which is not followed by a 
backslash should be stripped, because it is not visible otherwise (unlike in a 
normal string).

-Thorsten


> Am 13.04.2017 um 15:32 schrieb Adrian Zubarev via swift-evolution 
> :
> 
> Theoretically that would be enough and lightweight solution to that problem, 
> I could live with that. Optimally stripping them automatically would be 
> ideal, however I cannot tell how complicated this might be to implement.
> 
> A warning that will popup when you included any trailing spaces in a ‘content 
> line’ without the explicit backslash could also provide a fix-it to the user 
> to remove these spaces. However if you can emit that warning and calculate 
> the spaces to remove, than the compiler should be able to swallow these 
> characters by default right?
> 
> let s1 = """↵
> content·⇥···⇥··⇥↵
> 
> 
> s1 == "content" // => true
> The warning itself could bite with Xcode, it depends on who’s faster to 
> precede that problem. Either Xcode will strip them for you (but designing the 
> literal we should not rely on that), or the compiler will emit the warning 
> followed by Xcode which will strip them, which removes the warning. This 
> would be kind of silly right?
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 13. April 2017 um 15:10:36, John Holdsworth (m...@johnholdsworth.com 
> ) schrieb:
> 
>> Hi Adrian,
>> 
>> Would you settle for a warning for trailing whitespace in a literal?
>> Removing it is a bit fiddly to implement and I’m not sure it’s a feature.
>> 
>> John
>> 
>> 
>>> On 13 Apr 2017, at 14:05, Adrian Zubarev via swift-evolution 
>>> > wrote:
>>> 
>>> That would be so wrong, because it’s not obvious to anyone how long your 
>>> string will be.
>>> 
>>> """
>>> foo
>>> """
>>> I could tell you, that the string from above could have 10k characters, 
>>> even if you wouldn’t believe me, as it was proposed (and included in 
>>> yesterday’s toolchain) my claim can be true.
>>> 
>>> The trailing spaces needs to be stripped by the algorithm unless there is 
>>> an explicit precision annotation with a backslash!
>>> 
>>> """
>>> foo   \
>>> """
>>> That example definitely won’t have 10k characters.
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 13. April 2017 um 14:35:59, Ricardo Parada (rpar...@mac.com 
>>> ) schrieb:
>>> 
 Trailing whitespace 
 
 You also propose to remove trailing white space in each line unless the 
 whitespace is followed by a backslash.   For example:
 let str_2 = """↵
 foo··↵
 """
 The two trailing whitespaces after foo would get removed according to what 
 you are proposing. I don't like this rule. I think we are better off with 
 leaving it alone and to the tools as Brent suggested. 
>>> 
>>> 
>>> ___
>>> 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] Adding safety to arrays

[Karl Wagner via swift-evolution]

> I'd actually say the #1 reason not to add this feature is that a lot of 
> developers don't seem to understand this, and they're likely to use the 
> feature to make their code try to continue in the face of programmer error 
> instead of trapping like it properly should. A program in an inconsistent 
> state is dangerous; best to stop it quickly before it does some damage.)

Right, so I think the reason is actually that a lot of developers don’t 
understand what an Array is. There are two use-cases for an Array:

1) As a string of items, don’t care about the length. The maximum prior 
knowledge you can have is that the order may or may not be significant. This 
includes operations like iteration, mapping, reducing and filtering.
2) As a string of items of specific length. You have prior knowledge about what 
you expect to find at each location. This includes operations like 
random-access subscripting, which is what we’re talking about.

Basically, the interesting part of a statement such as “let someValue = 
myArray[2]” is: why index 2? What’s so special about that element; why couldn't 
someValue be the item at any index N instead? It’s because we know to expect 
something of special significance at index 2.

In that case, the only time myArray[2] will fail is when your prior knowledge 
breaks down. The type-system has no way to encode and check for the length of 
an Array, and that has allowed somebody to pass in a bad value. So what to do?

A) If you absolutely require a value for myArray[2]: Insert a precondition 
check.
B) If you can still continue without myArray[2]: Check the length of the Array. 
Your logic will be branching anyway in this case, to account for the value (and 
subsequent values) being/not being present.


Personally, the only valid use-case I can think of is when you want to 
initialise an Array’s elements out-of-order - i.e., you want to set a value for 
myArray[2] despite myArray[0] and [1] not being populated. In that case, it 
would be better to have some kind of SparseArray type, and for us to have a 
proper API for unsafe initialisation of stdlib types. 

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

What do you love about that?

> On Apr 14, 2017, at 8:40 AM, Muse M via swift-evolution 
>  wrote:
> 
> 3) 
> var code = {
> """
> Hello World
> """
> }
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Adding safety to arrays

[Douglas Gregor via swift-evolution]

> On Apr 13, 2017, at 5:19 AM, David Sweeris via swift-evolution 
>  wrote:
> 
>> 
>> On Apr 13, 2017, at 3:56 AM, Andrew Hart via swift-evolution 
>> > wrote:
>> 
>> Recently I’ve been considering the lack of safety around array indexes. 
>> Swift is designed with safety in mind, so this example would not compile:
>> 
>> var myString: String? = “hello”
>> myString.append(“ world!”)
>> 
>> The string is optional, not guaranteed to exist, so the last line requires a 
>> “!” to force-unwrap it.
>> 
>> 
>> 
>> public func tableView(_ tableView: UITableView, numberOfRowsInSection 
>> section: Int) -> Int {
>> let section = self.sections[section]
>> 
>> return section.items.count
>> }
>> 
>> In this example, we could provide a section number that goes beyond the 
>> bounds of the self.sections array, without any warning.
>> 
>> My suggestion is perhaps arrays should by default return an optional when 
>> given an index, and of course they’d support forced-unwrapping too. So you 
>> could then do this:
>> 
>> let section = self.sections[section]
>> if section == nil {
>> return 0
>> } else {
>> return section!.items.count
>> }
>> 
>> Or you could do this:
>> 
>> let section = self.sections[section]!
>> 
>> return section.items.count
>> 
>> Of course this would be less convenient in a lot of cases, but this is the 1 
>> place where apps seem to encounter a crash, crashing for the same reason 
>> that’s especially avoided across most of the rest of Swift.
> 
> My understanding is that we need the current behavior to meet performance 
> goals. We’ve discussed adding a “safe” subscript before, but the discussion 
> usually fizzles out when no clear winner for the argument label emerges.

Also, this discussion is common enough that it’s on the “commonly rejected” 
list:


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


- Doug


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

[swift-evolution] SE-0166: defaults for unmapped enums?

[Marc Schlichte via swift-evolution]

We sometimes encounter the situation that a server will add over time new 
values to existing `enums`.

e.g. in the `enum Animal` example `cat` gets added.

To not break existing clients, we often use something like this:

enum Animal: Int, Codable {
case unknown = 0
case chicken = 1, dog, turkey, cow
}

and all cases which are unknown (like a new `cat` case) will map to `unknown` 
instead.

I could probably do this by manually implementing `init(from:)`:

public init(from decoder: Decoder) throws {
// Decodes as a single value; no keys.
let intValue = try decoder.singleValueContainer().decode(Int.self)
if let value = Self(rawValue: intValue) {
self = value
} else {
self = .unknown
}
}

But maybe there is a better way envisioned by the authors of SE-0166?

Cheers
Marc


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

Re: [swift-evolution] [Proposal] Nested extensions

[Tino Heth via swift-evolution]

Hi Tony,

> Sorry to be a (hopefully polite) ogre, but from my perspective, your proposal 
> does not address nor nullify the issues with access modifier levels in Swift, 
> and I don’t think you should be pitching it as a stop-gap. It could make the 
> use of extensions consistent with other similar declarations, but ultimately 
> the access modifier level issues remain. 
Maybe this will be the case forever: Some people seem to have an affection for 
such things that goes far beyond my personal requirements, so I have no idea 
what someone else might come up with (I've already been joking about 
"cryptographic inheritance", which would allow you to override something only 
if you know the right transformation for the checksum of your new 
implementation ;-).
None the less, the concept is the most versatile I've have seen so far, yet it 
is less complex than some alternatives.

Right now, you can have your private properties in type declarations and 
extensions protected from all other types and extensions in the same file, and 
people say they want to have this option, so SE-0169 would hurt them.
Other people want same-file extensions to share private parts, and, at the same 
time, hide them from alien types in the same file (therefor, they don't want to 
use fileprivate).
Those two standpoints could coexist in Swift if we added another access 
modifier, but even if someone has a better name than 
"fileprivateButVisibleToSameTypeExtensionsInThisFile", this wouldn't be that 
nice…

Nested extensions, on the other hand, would require no new modifiers (actually, 
it would render fileprivate superfluous), and all you would have to do to have 
the effect of SE-0169 would be putting your extensions between an existing pair 
of curly braces, instead of placing them below that block.
I don't know about your specific issues with access levels, but the ones I have 
read about can be solved.

> - Can you clarify for me: does this proposal suggest allowing extensions on 
> the enclosing type to be nested within the type declaration, or within other 
> extensions on the original type? If so, can you please word that more clearly.
Both: Whatever is possible outside the curly braces should be possible between 
them as well (at least I have no spontaneous example for something that should 
be forbidden).

> - I would like to see some examples of the proposed syntax included in your 
> proposal (perhaps via a link to the markdown source on GitHub?). Best case 
> and worst case examples would show what impact it will have on readability 
> and file length when someone goes a bit nuts with this feature.
No rules will stop people doing stupid things, but I'd rather give the people a 
tool they could use to harm their codebase, instead of bugging all users of 
Swift by trying to make it foolproof.
The linked discussion has an example - I'll attach it here as well, because the 
HTML has no syntax colouring ;-)

> - Do you know how much work will be required to implement this change at this 
> stage? Is it feasible within the bounds of the time remaining before Swift 
> 4’s release?
Well, one major positive aspect of the idea is that there is no need to hurry:
I have an impression that we are in danger to make decisions without taking 
enough time to think about their consequences, just because a proposal should 
be part of the next release.
Nested extensions wouldn't break anything, so we could just leave this topic 
alone for now and include it in Swift 5 or 6 — or never, I someone has a better 
idea in the meantime.
SE-0169, on the other hand, would be yet another breaking change, and some 
people think it would harm Swift 4 and possible all versions to come after...

> Off-topic suggestion: Using the words “Simply” or “just” when describing work 
> to be done by others is something that you should avoid (unless you’ve 
> already implemented the feature and there’s a PR sitting on GitHub, ready to 
> go). Removing those words allows the sentences to communicate the same ideas, 
> but they no longer trivialise the size/scope of the work to be done during 
> implementation.
Oh yes, especially that last one — I did not find the fitting word yet, but I 
have to agree that this part could be interpreted in a way that wasn't intended.

> At this stage, I’m really not sure whether I’d add my support for this 
> proposal were it to go to review, but hopefully my comments are useful.

Well, I expected little more than a handful of comments saying "I like X 
better" and general disregard, so "I might support it" is already quite 
positive ;-)

- Tino

class MyVC: UIViewController {
private let numberOfSections = 0

extension: UITableViewDataSource {
// Skipping the class and assume we want to extend the surrounding type
func numberOfSections(in tableView: UITableView) -> Int {
return numberOfSections
}

func tableView(_ tableView: UITableView, numberOfRowsInSection section: 
Int) 

Re: [swift-evolution] [pitch] One-sided Ranges

[Haravikk via swift-evolution]

Apologies if this comes through as a duplicate for some people, but I'm not 
sure if it went through the first time; I seem to have some trouble with 
ProofPoint, who apparently do not monitor their false positive reporting 
system. As such my mail server is still listed from eight months ago despite 
never having a single spam message reported in that time, so pretty sure 
ProofPoint is a massive waste of money to anyone having it inflicted upon them, 
as it seemingly blocks entire servers with no negative rating.

Anyway, I'll repost for anyone that didn't get it the first time; if you 
ignored it the first time then feel free to do-so again, just know that it 
shall do irreparable harm to my fragile ego:



I like the principle in general, but I have some concerns about the range 
syntax. Firstly my concern is that allowing either end of the range to be 
omitted feels like a possible bug to me, so I'm not sure if we should encourage 
that?

I'm wondering if a slightly better alternative might to be to retain the 
operators as binary but to pass Void, like so:

let rangeFrom = 5...()
let rangeTo = ()...5

And so-on. It's not quite as pretty, but makes it clear that no mistake was 
made, and allows the operators to be defined normally taking two arguments of 
Comparable and Void (and vice versa).

It could be neatened up if we could allow a lone underscore as Void, like so:

let rangeFrom = 5..._
let rangeTo = _...5

This is a bit neater looking, and should be consistent with how underscore is 
used elsewhere? I'm not sure if it might conflict though, but I don't think so.

Just I thought, but I dislike the idea that by forgetting a value on a range, 
or making some other typo, I could accidentally define an open ended range and 
change the behaviour of something that accepts both open and closed ranges, I 
think requiring something that explicitly indicates an open range is a bit 
better.___
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

[Muse M via swift-evolution]

In Javascript, this counted as 2 lines which is fine for rendering code,
not with HTML5 elements
import Foundation
print("Hello World!")

1st)
In Swift, it's clear to start multi-line on a new line
var code =
*"""*
Hello World
*"""*

If Swift cannot accept the 1st syntax, below 2nd and 3rd syntax could be
done better
2nd)
*var code = """*
Hello World
*"""*

3)
*var code = {*
*"""*
Hello World
*"""*
}

I love the 3rd syntax.



On Fri, Apr 14, 2017 at 5:06 PM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> I think I found another argument of not to inject a new line after the
> last content line, even though it’s not a strong argument.
>
> Consider these two examples:
>
> let string_1 = """foo"""
>
>
> let string_2 = """
> foo
> """
>
> What’s the intuitive result you’d expect without taking all the long talk
> from the list into account?
>
> Personally, I’d say string_1 == string_2 is true.
>
> Now you’d might think how about the blank line as an example?
>
> let string_3 = """
>
> """
>
> However the equivalent for this would be:
>
> let string_4 = """\n"""
>
> Empty string in both variations:
>
> let string_5 = ""
>
>
> let string_6 = """
> """
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 14. April 2017 um 03:08:58, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
>
> On Thu, Apr 13, 2017 at 7:55 PM, Brent Royal-Gordon <
> br...@architechies.com> wrote:
>
>> On Apr 13, 2017, at 4:48 PM, Xiaodi Wu  wrote:
>>
>> You say "this is the example set by `print`", but I don't think anything
>>> else actually *follows* that example. No other I/O operation in Swift
>>> behaves this way.
>>>
>>
>> To be more accurate, it's not `print` that specifies this behavior, but
>> rather the standard output stream's implementation of
>> `TextOutputStream.write(_:)`. Swift *explicitly* leaves this choice up to
>> the TextOutputStream-conforming type. That is, the behavior is up to the
>> receiver and not the argument of a call to `TextOutputStream.write(_:)`.
>>
>>
>> I feel like I must be misunderstanding what you're trying to say here,
>> because I *think* what you're trying to say is that
>> `TextOutputStream.write(_:)` is what decides whether to add the terminator,
>> which is not only totally wrong (see https://github.com/apple/
>> swift/blob/adc54c8a4d13fbebfeb68244bac401ef2528d6d0/stdlib/
>> public/core/Print.swift#L260) but doesn't even make any sense since
>> there's a terminator parameter on `print` but none on `write(_:)`.
>>
>
> Hmm, you're right here with respect to `print()`. It is, however,
> explicitly contemplated in the documentation for
> `TextOutputStream.write(_:)` that conforming types can also determine
> whether or not to append a terminator, and which, inside their
> implementation of `write`. The example given in the documentation is:
>
> ```
> struct ASCIILogger: TextOutputStream {
> mutating func write(_ string: String) {
> let ascii = string.unicodeScalars.lazy.map { scalar in
> scalar == "\n"
>   ? "\n"
>   : scalar.escaped(asASCII: true)
> }
> print(ascii.joined(separator: ""), terminator: "")
> }
> }
> ```
>
>
>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>>
>
> ___
> 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] [Proposal] Nested extensions

[Xiaodi Wu via swift-evolution]

As I've mentioned three or four times already on this list, every time this
issue is brought up, the rules of access modifiers as revised in SE-0025
*cannot accommodate* non-top level extensions.

This is because an extension is not--and the core team is not willing to
change this despite several draft proposals--a first-class entity. The
access modifier for an extension indicates the default visibility for its
members but is not an upper bound, because a non-entity cannot bound its
members. Instead, it is an error to include anything with a higher access
modifier inside an extension.

The way this works with "private extension" is that enclosed members are
"fileprivate" by default. This only works because an extension is
guaranteed to be top level, and thus private is equal to fileprivate.

If an extension is not top level, then there is no way to spell the default
access level of a modifier inside a private extension. Therefore, the rules
for access modifiers in extensions need to be changed in order for your
proposal to be viable. You must detail how you propose to change them. I
should add, previous attempts to do so during the end of Swift 3 evolution
were not even allowed to come to review.


On Fri, Apr 14, 2017 at 04:40 Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> 
> Introduction
>
> By removing the restriction that extensions can only be used as top-level
> declarations, this important feature of Swift could become more powerful
> and solve issues some users have with access control.
>
> Swift-evolution thread: Enhancing access levels without breaking changes
> 
>
> 
> Motivation
>
> Currently, access control is a very hot topic for Swift, and all of the
> options discussed so far had strong resistance from different parts of the
> community.
>
> This concept tries to avoid all objections that were raised against the
> various modells (of course, it triggers fresh ones at the same time ;-),
> and because it is purely additive, it removes the pressure to address the
> current issues in Swift 4. Although it wasn't a motivation, the proposal
> also offers an answer to the question if (and how) properties should be
> allowed in extensions.
>
> SE-0169 would render major parts of this idea useless, so I think it's
> qualified to be discussed in this stage.
>
> Proposed
> solution
>
> Simply remove the restriction that extensions can only be declared on
> top-level of a file.
>
> Detailed
> design
>
> There isn't much to add here: Extensions should be allowed in type
> declarations and other extensions (I'm skipping methods in this draft - I
> see neither big problems associated with extensions declared inside
> methods, nor convincing use cases for them).
>
>-
>
>The rules should be the same as for nested types, so marking a member
>of an extension private would restrict its visiblity to the scope of this
>extension.
>-
>
>The goals of SE-0169 could be achieved in this model by simply putting
>an extension inside a type declaration, while keeping private members
>protected.
>
> Nested extensions should also be allowed to contain stored properties of
> the enclosing class, thus enabling better visibility management for those
> as well:
>
>-
>
>Stored properties in extensions have been requested before, but this
>approach enables them quite naturally, as the rule that you can only
>declare stored properties inside the declaration of a type is respected.
>-
>
>It would also be possible to levearage the "default access level"
>feature of extensions to group properties that should have the same
>visibility.
>
> Because there is no natural limit of nesting extensions, this feature
> enables developers to design more sophisticated systems of access rights,
> without increasing Swifts complexity for users that are happy with
> "puplic-internal-private" and don't see the need for additional keywords or
> other changes in the language.
>
> Future
> enhancements
>
> For extensions of an enclosing type, that type could be easily inferred,
> so some repetition could be eliminated easily.
>
> Source
> compatibility
>
> Purely additive
>
> Effect

Re: [swift-evolution] [Proposal] Nested extensions

[Jaden Geller via swift-evolution]

This proposal definitely needs to be more detailed, but I think I would be +1 
on the idea.

---

Use cases:

1) Extending nested types

// currently possible:
extension Foo.Bar {
  // must qualify some names with Foo
}

// could be possible:
extension Foo {
  extension Bar {
// everything in Foo is in scope
  }
}

2) Anonymous extensions

// stretch feature:
func foo() {
  extension Array {
// helpers used inside function
  }
}

---

Cheers,
Jaden Geller

> On Apr 14, 2017, at 2:40 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> 
> 
>  
> Introduction
> 
> By removing the restriction that extensions can only be used as top-level 
> declarations, this important feature of Swift could become more powerful and 
> solve issues some users have with access control.
> 
> Swift-evolution thread: Enhancing access levels without breaking changes 
> 
>  
> Motivation
> 
> Currently, access control is a very hot topic for Swift, and all of the 
> options discussed so far had strong resistance from different parts of the 
> community.
> 
> This concept tries to avoid all objections that were raised against the 
> various modells (of course, it triggers fresh ones at the same time ;-), and 
> because it is purely additive, it removes the pressure to address the current 
> issues in Swift 4. Although it wasn't a motivation, the proposal also offers 
> an answer to the question if (and how) properties should be allowed in 
> extensions.
> 
> SE-0169 would render major parts of this idea useless, so I think it's 
> qualified to be discussed in this stage.
> 
> 
>  
> Proposed
>  solution
> 
> Simply remove the restriction that extensions can only be declared on 
> top-level of a file.
> 
> 
>  
> Detailed
>  design
> 
> There isn't much to add here: Extensions should be allowed in type 
> declarations and other extensions (I'm skipping methods in this draft - I see 
> neither big problems associated with extensions declared inside methods, nor 
> convincing use cases for them).
> 
> The rules should be the same as for nested types, so marking a member of an 
> extension private would restrict its visiblity to the scope of this extension.
> 
> The goals of SE-0169 could be achieved in this model by simply putting an 
> extension inside a type declaration, while keeping private members protected.
> 
> Nested extensions should also be allowed to contain stored properties of the 
> enclosing class, thus enabling better visibility management for those as well:
> 
> Stored properties in extensions have been requested before, but this approach 
> enables them quite naturally, as the rule that you can only declare stored 
> properties inside the declaration of a type is respected.
> 
> It would also be possible to levearage the "default access level" feature of 
> extensions to group properties that should have the same visibility.
> 
> Because there is no natural limit of nesting extensions, this feature enables 
> developers to design more sophisticated systems of access rights, without 
> increasing Swifts complexity for users that are happy with 
> "puplic-internal-private" and don't see the need for additional keywords or 
> other changes in the language.
> 
> 
>  
> Future
>  enhancements
> 
> For extensions of an enclosing type, that type could be easily inferred, so 
> some repetition could be eliminated easily.
> 
> 
>  
> Source
>  compatibility
> 
> Purely additive
> 
> 
>  
> Effect
>  on ABI stability
> 
> There are some pitfalls associated with ABI, but I don't think its stability 
> would be affected.
> 
> 
>  
> Effect
>  on API resilience
> 
> Nono known
> 
> 
>  
> Alternatives
>  considered
> 
> SE-0169, SE-0159, renaming "fileprivate" and/or "private"
> 
> All of those possibilities have their own strengths and weaknesses, and there 
> is a huge dissent which of those are important: No matter which would be 
> choosen, at least one group of Swift users is punished.
> 
> 

Re: [swift-evolution] [Proposal] Nested extensions

[Tony Arnold via swift-evolution]

Hi Tino,

> On 14 Apr 2017, at 19:40, Tino Heth via swift-evolution 
>  wrote:
> 
> This concept tries to avoid all objections that were raised against the 
> various modells (of course, it triggers fresh ones at the same time ;-), and 
> because it is purely additive, it removes the pressure to address the current 
> issues in Swift 4.

Sorry to be a (hopefully polite) ogre, but from my perspective, your proposal 
does not address nor nullify the issues with access modifier levels in Swift, 
and I don’t think you should be pitching it as a stop-gap. It could make the 
use of extensions consistent with other similar declarations, but ultimately 
the access modifier level issues remain. 

My questions:

- Can you clarify for me: does this proposal suggest allowing extensions on the 
enclosing type to be nested within the type declaration, or within other 
extensions on the original type? If so, can you please word that more clearly.

- I would like to see some examples of the proposed syntax included in your 
proposal (perhaps via a link to the markdown source on GitHub?). Best case and 
worst case examples would show what impact it will have on readability and file 
length when someone goes a bit nuts with this feature.

- Do you know how much work will be required to implement this change at this 
stage? Is it feasible within the bounds of the time remaining before Swift 4’s 
release?



Off-topic suggestion: Using the words “Simply” or “just” when describing work 
to be done by others is something that you should avoid (unless you’ve already 
implemented the feature and there’s a PR sitting on GitHub, ready to go). 
Removing those words allows the sentences to communicate the same ideas, but 
they no longer trivialise the size/scope of the work to be done during 
implementation.



At this stage, I’m really not sure whether I’d add my support for this proposal 
were it to go to review, but hopefully my comments are useful.

Cheers,


Tony





--
Tony Arnold
+61 411 268 532
http://thecocoabots.com/

ABN: 14831833541

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

Re: [swift-evolution] [Proposal] Nested extensions

[Jonathan Hull via swift-evolution]

+1

> On Apr 14, 2017, at 2:40 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> 
> 
>  
> Introduction
> 
> By removing the restriction that extensions can only be used as top-level 
> declarations, this important feature of Swift could become more powerful and 
> solve issues some users have with access control.
> 
> Swift-evolution thread: Enhancing access levels without breaking changes 
> 
>  
> Motivation
> 
> Currently, access control is a very hot topic for Swift, and all of the 
> options discussed so far had strong resistance from different parts of the 
> community.
> 
> This concept tries to avoid all objections that were raised against the 
> various modells (of course, it triggers fresh ones at the same time ;-), and 
> because it is purely additive, it removes the pressure to address the current 
> issues in Swift 4. Although it wasn't a motivation, the proposal also offers 
> an answer to the question if (and how) properties should be allowed in 
> extensions.
> 
> SE-0169 would render major parts of this idea useless, so I think it's 
> qualified to be discussed in this stage.
> 
> 
>  
> Proposed
>  solution
> 
> Simply remove the restriction that extensions can only be declared on 
> top-level of a file.
> 
> 
>  
> Detailed
>  design
> 
> There isn't much to add here: Extensions should be allowed in type 
> declarations and other extensions (I'm skipping methods in this draft - I see 
> neither big problems associated with extensions declared inside methods, nor 
> convincing use cases for them).
> 
> The rules should be the same as for nested types, so marking a member of an 
> extension private would restrict its visiblity to the scope of this extension.
> 
> The goals of SE-0169 could be achieved in this model by simply putting an 
> extension inside a type declaration, while keeping private members protected.
> 
> Nested extensions should also be allowed to contain stored properties of the 
> enclosing class, thus enabling better visibility management for those as well:
> 
> Stored properties in extensions have been requested before, but this approach 
> enables them quite naturally, as the rule that you can only declare stored 
> properties inside the declaration of a type is respected.
> 
> It would also be possible to levearage the "default access level" feature of 
> extensions to group properties that should have the same visibility.
> 
> Because there is no natural limit of nesting extensions, this feature enables 
> developers to design more sophisticated systems of access rights, without 
> increasing Swifts complexity for users that are happy with 
> "puplic-internal-private" and don't see the need for additional keywords or 
> other changes in the language.
> 
> 
>  
> Future
>  enhancements
> 
> For extensions of an enclosing type, that type could be easily inferred, so 
> some repetition could be eliminated easily.
> 
> 
>  
> Source
>  compatibility
> 
> Purely additive
> 
> 
>  
> Effect
>  on ABI stability
> 
> There are some pitfalls associated with ABI, but I don't think its stability 
> would be affected.
> 
> 
>  
> Effect
>  on API resilience
> 
> Nono known
> 
> 
>  
> Alternatives
>  considered
> 
> SE-0169, SE-0159, renaming "fileprivate" and/or "private"
> 
> All of those possibilities have their own strengths and weaknesses, and there 
> is a huge dissent which of those are important: No matter which would be 
> choosen, at least one group of Swift users is punished.
> 
> ___
> 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] [Proposal] Nested extensions

[Tino Heth via swift-evolution]

 
Introduction

By removing the restriction that extensions can only be used as top-level 
declarations, this important feature of Swift could become more powerful and 
solve issues some users have with access control.

Swift-evolution thread: Enhancing access levels without breaking changes 

 
Motivation

Currently, access control is a very hot topic for Swift, and all of the options 
discussed so far had strong resistance from different parts of the community.

This concept tries to avoid all objections that were raised against the various 
modells (of course, it triggers fresh ones at the same time ;-), and because it 
is purely additive, it removes the pressure to address the current issues in 
Swift 4. Although it wasn't a motivation, the proposal also offers an answer to 
the question if (and how) properties should be allowed in extensions.

SE-0169 would render major parts of this idea useless, so I think it's 
qualified to be discussed in this stage.


 
Proposed
 solution

Simply remove the restriction that extensions can only be declared on top-level 
of a file.


 
Detailed
 design

There isn't much to add here: Extensions should be allowed in type declarations 
and other extensions (I'm skipping methods in this draft - I see neither big 
problems associated with extensions declared inside methods, nor convincing use 
cases for them).

The rules should be the same as for nested types, so marking a member of an 
extension private would restrict its visiblity to the scope of this extension.

The goals of SE-0169 could be achieved in this model by simply putting an 
extension inside a type declaration, while keeping private members protected.

Nested extensions should also be allowed to contain stored properties of the 
enclosing class, thus enabling better visibility management for those as well:

Stored properties in extensions have been requested before, but this approach 
enables them quite naturally, as the rule that you can only declare stored 
properties inside the declaration of a type is respected.

It would also be possible to levearage the "default access level" feature of 
extensions to group properties that should have the same visibility.

Because there is no natural limit of nesting extensions, this feature enables 
developers to design more sophisticated systems of access rights, without 
increasing Swifts complexity for users that are happy with 
"puplic-internal-private" and don't see the need for additional keywords or 
other changes in the language.


 
Future
 enhancements

For extensions of an enclosing type, that type could be easily inferred, so 
some repetition could be eliminated easily.


 
Source
 compatibility

Purely additive


 
Effect
 on ABI stability

There are some pitfalls associated with ABI, but I don't think its stability 
would be affected.


 
Effect
 on API resilience

Nono known


 
Alternatives
 considered

SE-0169, SE-0159, renaming "fileprivate" and/or "private"

All of those possibilities have their own strengths and weaknesses, and there 
is a huge dissent which of those are important: No matter which would be 
choosen, at least one group of Swift users is punished.___
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 I found another argument of not to inject a new line after the last 
content line, even though it’s not a strong argument.

Consider these two examples:

let string_1 = """foo"""


let string_2 = """
foo
"""
What’s the intuitive result you’d expect without taking all the long talk from 
the list into account?

Personally, I’d say string_1 == string_2 is true.

Now you’d might think how about the blank line as an example?

let string_3 = """

"""
However the equivalent for this would be:

let string_4 = """\n"""
Empty string in both variations:

let string_5 = ""


let string_6 = """
"""


-- 
Adrian Zubarev
Sent with Airmail

Am 14. April 2017 um 03:08:58, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

On Thu, Apr 13, 2017 at 7:55 PM, Brent Royal-Gordon  
wrote:
On Apr 13, 2017, at 4:48 PM, Xiaodi Wu  wrote:

You say "this is the example set by `print`", but I don't think anything else 
actually *follows* that example. No other I/O operation in Swift behaves this 
way.

To be more accurate, it's not `print` that specifies this behavior, but rather 
the standard output stream's implementation of `TextOutputStream.write(_:)`. 
Swift *explicitly* leaves this choice up to the TextOutputStream-conforming 
type. That is, the behavior is up to the receiver and not the argument of a 
call to `TextOutputStream.write(_:)`.

I feel like I must be misunderstanding what you're trying to say here, because 
I *think* what you're trying to say is that `TextOutputStream.write(_:)` is 
what decides whether to add the terminator, which is not only totally wrong 
(see 
https://github.com/apple/swift/blob/adc54c8a4d13fbebfeb68244bac401ef2528d6d0/stdlib/public/core/Print.swift#L260)
 but doesn't even make any sense since there's a terminator parameter on 
`print` but none on `write(_:)`.

Hmm, you're right here with respect to `print()`. It is, however, explicitly 
contemplated in the documentation for `TextOutputStream.write(_:)` that 
conforming types can also determine whether or not to append a terminator, and 
which, inside their implementation of `write`. The example given in the 
documentation is:

```
struct ASCIILogger: TextOutputStream {
    mutating func write(_ string: String) {
        let ascii = string.unicodeScalars.lazy.map { scalar in
            scalar == "\n"
              ? "\n"
              : scalar.escaped(asASCII: true)
        }
        print(ascii.joined(separator: ""), terminator: "")
    }
}
```



-- 
Brent Royal-Gordon
Architechies


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