Re: [swift-evolution] guard let x = x

+1 Can “unwrap” be used anywhere else? If not, why not remove the “guard” altogether? I.e. unwrap foobar else { … } Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 29 Oct 2016, at 00:34, Er

Re: [swift-evolution] [Meta] Let's talk TouchBar + Unicode

> On 29 Oct 2016, at 04:22, Xiaodi Wu via swift-evolution > wrote: > > The other has to do with expanding Swift standard library and core library > APIs beyond the ASCII character set. I'm -1 on that for the reasons I've > outlined above. Reworded, a very good reason to limit the standard libr

Re: [swift-evolution] [Meta] Let's talk TouchBar + Unicode

There are two proposals in here that you're mixing together. One has to do with improvements to Xcode for working with Unicode. I'd be all for that, as I've just said, but afaict this is not in scope for Swift evolution. The other has to do with expanding Swift standard library and core library A

Re: [swift-evolution] guard let x = x

I think we should just have an “Unwrappable” protocol with a function/property that gets called by the statement. Then types can just define it for themselves based on whatever makes sense. That, or Xiaodi’s idea for union types (since I really want union types) Thanks, Jon > > On Oct 28, 20

Re: [swift-evolution] [Meta] Let's talk TouchBar + Unicode

> On Oct 28, 2016, at 5:45 PM, Xiaodi Wu wrote: > > -1. I'm all for full and complete Unicode support in Swift so that each > person can use their native language to the fullest. But there is value in > saying that the working language for Swift evolution is U.S. English, the > working langua

Re: [swift-evolution] [Meta] Let's talk TouchBar + Unicode

You are against even making it simpler to type/use the characters for those who want to use them? Hardcore. > On Oct 28, 2016, at 5:45 PM, Xiaodi Wu wrote: > > -1. I'm all for full and complete Unicode support in Swift so that each > person can use their native language to the fullest. But t

Re: [swift-evolution] guard let x = x

Sounds good to me. Leaving the gist in its updated state (a little further from the last time) for the record. -- E > On Oct 28, 2016, at 7:02 PM, Xiaodi Wu wrote: > > Granted that this whole topic is out of scope currently, I think the enum > unwrapping facility is its own subject entirely,

Re: [swift-evolution] guard let x = x

Granted that this whole topic is out of scope currently, I think the enum unwrapping facility is its own subject entirely, separable from the `if let x = x` sugar. Approaching this issue from another perspective--namely, improving enums to better enable some use cases prompted by requests for unio

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

As Chris mentioned, such a proposal is entirely out of scope for this phase of Swift 4, it's a commonly rejected proposal that required a high bar for reconsideration even during the Swift 3 evolution process, and that bar is even higher going forward because source breaking changes will be extreme

Re: [swift-evolution] Promises, Futures and the death of the callback hell

Async and related topics are deferred until the spring; I would imagine promises fall into the same basket. On Fri, Oct 28, 2016 at 7:46 PM Florent Vilmart via swift-evolution < swift-evolution@swift.org> wrote: > Has this subject been already addressed? Is it worth considering here? > > I searche

Re: [swift-evolution] [Meta] Let's talk TouchBar + Unicode

-1. I'm all for full and complete Unicode support in Swift so that each person can use their native language to the fullest. But there is value in saying that the working language for Swift evolution is U.S. English, the working language for the Swift standard library API is U.S. English, and the w

[swift-evolution] Promises, Futures and the death of the callback hell

Has this subject been already addressed? Is it worth considering here? I searched the repo for Futures and Promises, and it seems that no proposal has been opened yet. F. signature.asc Description: Message signed with OpenPGP using AMPGpg ___ swift-ev

Re: [swift-evolution] guard let x = x

> On Oct 28, 2016, at 6:22 PM, Erica Sadun via swift-evolution > wrote: >> On Oct 28, 2016, at 5:55 PM, Kevin Nattinger > > wrote: >>> On Oct 28, 2016, at 4:45 PM, Erica Sadun via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: On Oct 28, 2016, at

[swift-evolution] [Meta] Let's talk TouchBar + Unicode

Given that Swift supports unicode, and it looks like this TouchBar will make typing relevant characters/symbols much more accessible/discoverable, I think we should move forward with the assumption that we will be able to type (somehow) whatever symbol we feel best represents something, and we s

Re: [swift-evolution] guard let x = x

> On Oct 28, 2016, at 16:45, Erica Sadun wrote: > > >> On Oct 28, 2016, at 5:00 PM, Huon Wilson > > wrote: >> >> >>> On Oct 28, 2016, at 15:34, Erica Sadun via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>>

Re: [swift-evolution] guard let x = x

> > On Oct 28, 2016, at 5:55 PM, Kevin Nattinger wrote: > >> >> On Oct 28, 2016, at 4:45 PM, Erica Sadun via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Oct 28, 2016, at 5:00 PM, Huon Wilson >> > wrote: >>> >>> On Oct 28, 2016, at 1

Re: [swift-evolution] guard let x = x

> On Oct 28, 2016, at 4:45 PM, Erica Sadun via swift-evolution > wrote: > > >> On Oct 28, 2016, at 5:00 PM, Huon Wilson > > wrote: >> >> >>> On Oct 28, 2016, at 15:34, Erica Sadun via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>>

Re: [swift-evolution] guard let x = x

> On Oct 28, 2016, at 5:00 PM, Huon Wilson wrote: > > >> On Oct 28, 2016, at 15:34, Erica Sadun via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Detailed >> Design >> >> unwrap can be used

Re: [swift-evolution] guard let x = x

> On Oct 28, 2016, at 15:34, Erica Sadun via swift-evolution > wrote: > > Detailed > Design > > unwrap can be used with any one-value enumeration. The unwrapped value is > bound to the same symbol as the associa

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Just to play devil’s advocate (since I am honestly ok with the less draconian form of the proposal now), wouldn’t it be possible to declare the relevant unicode characters in the module’s plist (or similar file)? I know it isn’t the most elegant solution, but it does move the bar on using those

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

True, but that doesn’t mean we have to resign ourselves the lowest common denominator. We need a way to operate with older systems, but we also want to embrace what has been made possible now. Within a few years, it is quite likely that this technology will be common both across Apple’s lineup

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

+1 from me as well. I was initially unconvinced, until Charlotte showed me her proposal. She lays out the case very well, and I agreed to help edit the proposal. It’s a confusing and bad operator, and it doesn’t give us anything that a function on Bool can’t give us. The way I see it, this isn’

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 25, 2016, at 3:19 AM, Xiaodi Wu wrote: > > Unfortunately, Joe is correct on this point. As I stated earlier in the > thread, there are a series of characters that can be either text or emoji in > presentation, where the default presentation differs depending on platform, > technology

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

And there’s our confirmation of hardware emoji keyboard. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

> On Oct 25, 2016, at 11:38 AM, Jay Abbott via swift-evolution > wrote: > > I mentioned this in passing on a different thread > . > Although it caused some slight confusion when I first learned the 'guard' > k

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

-1 to replacing this with the functions mentioned. At some point, I would like to see an operator which lifts a value into an optional based on a boolean value (basically the opposite of ??). That is it is either the value or nil based on some boolean value. If we use ‘?’ as a binary operator

Re: [swift-evolution] guard let x = x

> On Oct 26, 2016, at 11:39 AM, Chris Lattner via swift-evolution > wrote: > > >> On Oct 26, 2016, at 10:23 AM, Joshua Alvarado >> wrote: >> >> In your example the keyword only makes sense if you are shadowing the >> optional variable. How would unwrap work with a different name? > > It w

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

I'm not aware of any Unicode stipulations on rendering of unassigned code points. In any case, Swift _n_ doesn't need to be designed around specific platforms that exist in 2016, but it'd be perfectly sensible to say that Swift 4 should restrict valid identifiers to those characters that are displa

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 27, 2016, at 11:46 AM, Jonathan Hull via swift-evolution > wrote: > > It looks like the issue of typing unicode symbols was solved much sooner than > any of us were predicting… > > Thanks, > Jon Swift as a language extends beyond Apple's platform and Unicode symbology. -- E _

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

+1 -Thorsten > Am 20.10.2016 um 02:32 schrieb Nevin Brackett-Rozinsky via swift-evolution > : > > I strongly oppose the proposed mass-removal of operator characters. It would > be a major loss to the Swift language if that were to occur even temporarily. > > The long-term goal is for Swift t

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

> On 28 Oct 2016, at 10:00, Jeremy Pereira > wrote: > > >> On 25 Oct 2016, at 13:15, Haravikk wrote: >> >> >> I'm inclined to disagree; the keyword wouldn't be much different from the >> use of the is keyword to test a type (I even suggested using it since it's >> shorter than matches and

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

It looks like the issue of typing unicode symbols was solved much sooner than any of us were predicting… Thanks, Jon ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

I’d like to put in a word in appreciate of such a careful presentation of the idea. While it doesn’t change the fact that this is out of scope for Swift 4, it’s nice to read something so thoughtfully spelled out. Charlotte, I hope you’ll keep bringing your ideas. FWIW, while I rather like the t

Re: [swift-evolution] guard let x = x

> On Oct 26, 2016, at 9:37 AM, Chris Lattner via swift-evolution > wrote: > To me, this is the most promising direction, but I’d suggest the use of > “unwrap" as the keyword. If you compare these two: > > a) guard let foobar = foobar else { … } > b) guard unwrap foobar else { … } > > I thin

Re: [swift-evolution] [Pitch] Expanded type category constraints

> On Oct 27, 2016, at 4:15 AM, David Sweeris via swift-evolution > wrote: > > I keep losing track of what exactly constitutes "ABI stability and resilience" ABI stability can generally be thought of as "anything that affects how APIs **that exist today** are represented in machine code". That

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

> On 25 Oct 2016, at 13:15, Haravikk wrote: > > > I'm inclined to disagree; the keyword wouldn't be much different from the use > of the is keyword to test a type (I even suggested using it since it's > shorter than matches and wouldn't require a new term), both are run-time > operations exc