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

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 f

[swift-evolution] [Proposal] Nested extensions

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 wit

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

+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, th

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

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 ad

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

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 F

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

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 d

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

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 c

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

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 despi

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

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 simil

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

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 chicke

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

> 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 >> mailto:swift-evolution@swift.org>> wrote: >> >> Recently I’ve been considering the lack of safety around array indexes. >> Swift is designed with

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

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/

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

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

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

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

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

Honestly, 1) is ugly, we don’t want to add a useless new line restriction there, 2) is what I’m pushing in this discussion. 3) is very ugly syntax. --  Adrian Zubarev Sent with Airmail Am 14. April 2017 um 14:40:48, Muse M (james.le...@gmail.com) schrieb: In Javascript, this counted as 2 line

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

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 char

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

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

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

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

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

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

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

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 communit

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

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,

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

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

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

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

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

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 prop

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

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

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

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://

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

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

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

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 flo

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

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 lev

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

> 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: NSNu

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

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 modi

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

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

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

> 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

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

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

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

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 increa

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

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 l

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

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 ch

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

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

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

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

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

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

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

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

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

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 th

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

> 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

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

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 peop

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

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

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

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

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

+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-evo

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

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

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

If we're to talk about ideas and needs, my favored access control design is one that pares back to only two modifiers: public and internal. Either the thing is public API, or it is not. Ditch everything else. On Fri, Apr 14, 2017 at 19:42 Tony Arnold via swift-evolution < swift-evolution@swift.org>

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

Sure: One solution to the problem is to remove the use of access modifiers as a shorthand in front of extensions. It was proposed, reviewed, and rejected: https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md The discussion was here: https://lists.swif

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

> On Apr 12, 2017, at 6:09 AM, Ricardo Parada wrote: > > > On Apr 12, 2017, at 1:42 AM, Chris Lattner via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Apr 11, 2017, at 10:30 PM, David Hart > > wrote: To me, the reason for limiting it to a

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

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 ho

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

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 parse

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

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 ty

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

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 ex

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

> • What is your evaluation of the proposal? +1 This is a small, but very useful addition. I like the argument label `into`, and using it to distinguish between the two implementations. > • Is the problem being addressed significant enough to warrant a change > to Swift? Yes. Redu