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

[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

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

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

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 > > wrote: > >> On Apr 11, 2017, at 10:30 PM, David Hart >

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

> 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

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

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.

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

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

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

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

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

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

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

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

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

[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

[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

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

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

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

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

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

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 >> > wrote: >> >> Recently I’ve been considering the lack of

[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

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

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

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

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

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

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,

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

[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

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