Re: [swift-evolution] Calling a Specific Implementation

> On Aug 18, 2016, at 8:21 PM, Ben Rimmington via swift-evolution > wrote: > > >> On 18 Aug 2016, at 16:32, John McCall wrote: >> >> Unapplied method references still dispatch down. It's a pretty simple >> experiment to run for yourself. > >

Re: [swift-evolution] try? shouldn't work on non-method-call

I do think that the status quo is good for try? precedence and such, but how about the original problem? The code was hard to work with because it used a double nested Optional. If you really don’t care about the reason that code failed, then a single optional should be returned. There’s

Re: [swift-evolution] Allow trailing comma in guard, if-let, et al

> On Aug 17, 2016, at 18:11 , Ben Rimmington wrote: > > >> On 18 Aug 2016, at 00:13, Rick Mann wrote: >> >> Is there any reason Swift can't allow a trailing comma in constructs like >> this: >> >> guard >> let a = ..., >> let b = ..., >> let c = ..., >> else >>

Re: [swift-evolution] InternalString class for easy String manipulation

When I say reinterpret, I mean taking the UTF-8 bytes and pretend that theyre UTF-16. This is an extremely clear bug whenever it happens. The correct conversion between UTF-8 and UTF-16 is lossless. The vast majority of systems, including file systems and email addresses, support Unicode. Im

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

Hi Tim, Thanks for bringing this up. Here are my thoughts on the change you’re proposing. func sequence(first: T, next: (T) -> T?) -> UnfoldFirstSequence To me the type of the function as it is tells a clear story of what’s going to happen: take the `first`, make it a head of the resulting

Re: [swift-evolution] PITCH: New :== operator for generic constraints

Slava and Joe's suggestion of self conformance and the constraints involved are something that's been explored in other languages with similar systems. There's a great series of posts discussing some of the issues at hand: These describe the constraints of interest (“object safety”):

Re: [swift-evolution] InternalString class for easy String manipulation

Actually, if I'm not mistaken, String (or at least, CFStringRef, to which String is toll-free bridged) does not re-encode anything eagerly. If you initialize with UTF8 bytes, it's stored internally as UTF8 bytes; if you initialize with UTF16 code units, it's stored internally as UTF16 code units.

Re: [swift-evolution] InternalString class for easy String manipulation

> On Aug 18, 2016, at 11:51 AM, Félix Cloutier wrote: > Of course you'll have problems if you try to interpret UTF-8 as UTF-16 and > vice-versa, but that'll do you regardless of whether you use international > characters or not. This is exactly my point. Even if the

Re: [swift-evolution] try? shouldn't work on non-method-call

On Thu, Aug 18, 2016 at 1:20 PM, John McCall wrote: > On Aug 18, 2016, at 10:11 AM, Xiaodi Wu wrote: > On Thu, Aug 18, 2016 at 11:30 AM, John McCall wrote: > >> On Aug 18, 2016, at 8:46 AM, Xiaodi Wu wrote: >>

Re: [swift-evolution] InternalString class for easy String manipulation

I'm not sure I understand your comment. UTF-8 and UTF-16 are just two different ways to represent Unicode data, and they can both encode the whole range of Unicode. Of course you'll have problems if you try to interpret UTF-8 as UTF-16 and vice-versa, but that'll do you regardless of whether

Re: [swift-evolution] [swift-dev] SE-0111 related question

On Aug 18, 2016, at 11:10 AM, Douglas Gregor via swift-evolution wrote: > >> If we agree that parameter are part of the name, then it should behave just >> like a name. Specifying names shouldn't matter more than the name of the >> variable storing the closure. It

Re: [swift-evolution] try? shouldn't work on non-method-call

> On Aug 18, 2016, at 10:11 AM, Xiaodi Wu wrote: > On Thu, Aug 18, 2016 at 11:30 AM, John McCall > wrote: >> On Aug 18, 2016, at 8:46 AM, Xiaodi Wu > > wrote: >> The issue

Re: [swift-evolution] [swift-dev] SE-0111 related question

> On Aug 18, 2016, at 11:17 AM, Xiaodi Wu wrote: > > On Thu, Aug 18, 2016 at 1:10 PM, Douglas Gregor via swift-evolution > > wrote: > >> On Aug 18, 2016, at 9:52 AM, Benjamin G via swift-dev

Re: [swift-evolution] [swift-dev] SE-0111 related question

On Thu, Aug 18, 2016 at 1:10 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > > On Aug 18, 2016, at 9:52 AM, Benjamin G via swift-dev > wrote: > > Sorry for mentioning this issue again, as it seems to have been already > much discussed, but i've

Re: [swift-evolution] [swift-dev] SE-0111 related question

> On Aug 18, 2016, at 9:52 AM, Benjamin G via swift-dev > wrote: > > Sorry for mentioning this issue again, as it seems to have been already much > discussed, but i've had the unfortunate experience of dealing with the > consequences of this proposal in my code since

Re: [swift-evolution] try? shouldn't work on non-method-call

> On Aug 18, 2016, at 10:56 AM, Davor Jankolija wrote: >> On 18 Aug 2016, at 19:46, John McCall > > wrote: >> >>> On Aug 18, 2016, at 10:15 AM, Davor Jankolija via swift-evolution >>>

Re: [swift-evolution] try? shouldn't work on non-method-call

> On 18 Aug 2016, at 19:46, John McCall wrote: > >> On Aug 18, 2016, at 10:15 AM, Davor Jankolija via swift-evolution >> wrote: >> >>> This is a warning right now — do you think it should be an error? >>> >>> Slavas-MacBook-Pro:~ slava$ cat

Re: [swift-evolution] try? shouldn't work on non-method-call

> On Aug 18, 2016, at 10:15 AM, Davor Jankolija via swift-evolution > wrote: > >> This is a warning right now — do you think it should be an error? >> >> Slavas-MacBook-Pro:~ slava$ cat ttt.swift >> func f() {} >> >> func g() { >> try f() >> try? f() >> } >> >>

Re: [swift-evolution] try? shouldn't work on non-method-call

> This is a warning right now — do you think it should be an error? > > Slavas-MacBook-Pro:~ slava$ cat ttt.swift > func f() {} > > func g() { > try f() > try? f() > } > > Slavas-MacBook-Pro:~ slava$ swiftc ttt.swift > ttt.swift:4:3: warning: no calls to throwing functions occur within

Re: [swift-evolution] try? shouldn't work on non-method-call

On Thu, Aug 18, 2016 at 11:30 AM, John McCall wrote: > On Aug 18, 2016, at 8:46 AM, Xiaodi Wu wrote: > The issue would be that, in the case of "try? foo()", nil and .some(nil) > might mean very different things. > > > This is true of a?.foo() as well.

Re: [swift-evolution] InternalString class for easy String manipulation

>> Just because you are using UTF-8 as the internal format, it does not mean >> that universal support is guaranteed. All I meant was this, and nothing more. If the internal format was UTF-8, and you were using a filesystem whose filenames were UTF-16, you would have the same problems. -Kenny

Re: [swift-evolution] try? shouldn't work on non-method-call

> On Aug 18, 2016, at 8:46 AM, Xiaodi Wu wrote: > The issue would be that, in the case of "try? foo()", nil and .some(nil) > might mean very different things. This is true of a?.foo() as well. But yes, I think it is more likely that someone would want to treat them

Re: [swift-evolution] try? shouldn't work on non-method-call

The issue would be that, in the case of "try? foo()", nil and .some(nil) might mean very different things. On Thu, Aug 18, 2016 at 10:40 John McCall wrote: > On Aug 18, 2016, at 8:19 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > Lots of

Re: [swift-evolution] try? shouldn't work on non-method-call

> On Aug 18, 2016, at 8:19 AM, Xiaodi Wu via swift-evolution > wrote: > > Lots of interesting points here. I do think there's an improvement possible > here, but it's actually along the lines of Sam's original suggestion #3 (not > vis-a-vis all of Swift, but

Re: [swift-evolution] Calling a Specific Implementation

> On Aug 17, 2016, at 7:24 PM, Ben Rimmington wrote: >> On 18 Aug 2016, at 02:57, John McCall wrote: >> >> Being able to bypass another class's overrides and jump to a specific >> superclass implementation on an arbitrary method call is badly >> encapsulation-breaking,

Re: [swift-evolution] try? shouldn't work on non-method-call

On Thu, Aug 18, 2016 at 10:19 AM, Xiaodi Wu wrote: > Lots of interesting points here. I do think there's an improvement > possible here, but it's actually along the lines of Sam's original > suggestion #3 (not vis-a-vis all of Swift, but specifically for how try? > composes

Re: [swift-evolution] try? shouldn't work on non-method-call

Lots of interesting points here. I do think there's an improvement possible here, but it's actually along the lines of Sam's original suggestion #3 (not vis-a-vis all of Swift, but specifically for how try? composes with as?): A. I'm in favor of the current behavior where try prefixes an entire

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

While purpose of the types are clear in this case there is not only intersection. I also want to find out the distance between different GeometryTypes and other properties like angels between two lines or a Line and a Plane but this doesn't make sense for a Point and some other GeometryType.

Re: [swift-evolution] try? shouldn't work on non-method-call

> On Aug 18, 2016, at 3:42 PM, Slava Pestov wrote: > >> >> On Aug 18, 2016, at 12:52 AM, David Hart via swift-evolution >> > wrote: >> >> Opinions inline: >> >>> On 18 Aug 2016, at 07:43, Sikhapol Saijit via

Re: [swift-evolution] try? shouldn't work on non-method-call

> On Aug 18, 2016, at 1:42 AM, Slava Pestov via swift-evolution > wrote: > >> >> On Aug 18, 2016, at 12:52 AM, David Hart via swift-evolution >> > wrote: >> >> Opinions inline: >> >>> On 18 Aug 2016, at

Re: [swift-evolution] try? shouldn't work on non-method-call

> On Aug 18, 2016, at 12:52 AM, David Hart via swift-evolution > wrote: > > Opinions inline: > >> On 18 Aug 2016, at 07:43, Sikhapol Saijit via swift-evolution >> > wrote: >> >> Hi all, >> >> >>

Re: [swift-evolution] try? shouldn't work on non-method-call

> On Aug 18, 2016, at 3:15 PM, Charles Srstka wrote: > > Sorry for the resend! Some of my previous e-mail was left out for some > reason. Here it is again, as it should have been: > >> On Aug 18, 2016, at 12:43 AM, Sikhapol Saijit via swift-evolution >>

Re: [swift-evolution] try? shouldn't work on non-method-call

Sorry for the resend! Some of my previous e-mail was left out for some reason. Here it is again, as it should have been: > On Aug 18, 2016, at 12:43 AM, Sikhapol Saijit via swift-evolution > > wrote: > > 1. Is it intentional that

Re: [swift-evolution] try? shouldn't work on non-method-call

> On Aug 18, 2016, at 12:43 AM, Sikhapol Saijit via swift-evolution > wrote: > > 1. Is it intentional that try? can be used with a "non-method-call" and > return an optional of the type that follows? a. I’m not sure what you mean by “non-method-call”, since the

Re: [swift-evolution] try? shouldn't work on non-method-call

Opinions inline: > On 18 Aug 2016, at 07:43, Sikhapol Saijit via swift-evolution > wrote: > > Hi all, > > > Yesterday I tried this code: > > func couldFailButWillNot() throws -> Any { > return 42 > } > > if let a = try? couldFailButWillNot() as? Int { >

Re: [swift-evolution] [Pitch][stdlib] Command Line Option Parsing & Help

> On Aug 17, 2016, at 9:41 AM, Will Field-Thompson via swift-evolution > wrote: > > I think it would be great to have something like this (at least the > "Arguments" component) as part of the standard distribution — maybe as a > corelib rather than as part of the