Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 8, 2016, at 6:57 AM, Thorsten Seitz > wrote: > > I strongly disagree. Type systems are not some esoteric academic thing only > working for Haskell or functional languages. Just have a look at the type > systems of other languages

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 8, 2016, at 6:57 AM, Thorsten Seitz wrote: > > I strongly disagree. Type systems are not some esoteric academic thing only > working for Haskell or functional languages. Just have a look at the type > systems of other languages like Ceylon, Rust or TypeScript. >

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

Am 08.06.2016 um 01:36 schrieb Brent Royal-Gordon via swift-evolution : >> A return type makes a lot of sense linguistically but does not cover all >> practical cases because you might not be the one deciding what the >> function's signature is. For example, you

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> Am 07.06.2016 um 23:32 schrieb Michael Peternell via swift-evolution > : > > Ok, one last thing, then I go to sleep for today... > > Basic Definition of a "Type": > I learned in university that a type is a "set of values". Yep. And because sets can be empty there

Re: [swift-evolution] [proposal] Allow function argument type to be omitted when passing a default value from which it can be inferred

> On 07 Jun 2016, at 22:08, Sam Dods via swift-evolution > wrote: > > yes, exactly Doug... the properties at type level are part of the interface > and their types can be inferred, so i don't see the difference with function > argument types. > > i just find it

Re: [swift-evolution] SE-0045 status?

> On Jun 7, 2016, at 9:37 PM, Chris Lattner wrote: > > >> On Jun 6, 2016, at 8:35 AM, Erica Sadun via swift-evolution >> wrote: >> >> Did we ever get to a stopping point on SE-0045, with the take while / drop >> while methods? I remember we

Re: [swift-evolution] [Proposal] Enum subsets

On Jun 5, 2016, at 8:24 PM, T.J. Usiyan via swift-evolution wrote: > Sub typing is the answer that we're going with then? Most likely. At this point, we’re not really accepting additive changes to Swift 3 anyway, so any proposal would need to wait until post-swift 3

Re: [swift-evolution] [Rejected] SE-0097: Normalizing naming for "negative" attributes

> On Jun 1, 2016, at 11:29 PM, Jacob Bandes-Storch wrote: > > On Wed, Jun 1, 2016 at 10:25 PM, Chris Lattner > wrote: > On Jun 1, 2016, at 9:28 PM, Jacob Bandes-Storch >

Re: [swift-evolution] SE-0045 status?

> On Jun 6, 2016, at 8:35 AM, Erica Sadun via swift-evolution > wrote: > > Did we ever get to a stopping point on SE-0045, with the take while / drop > while methods? I remember we were discussing using prefix / suffix and a > bunch of other names, but was the

Re: [swift-evolution] Marking sort and sorted with rethrows

> On Jun 7, 2016, at 12:07 PM, Tim Vermeulen via swift-evolution > wrote: > >> True, but the cost of being able to restore the original ordering, when >> that restoration may not be needed at all, is prohibitive. > > What about simply restoring the elements, in no

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 7, 2016, at 9:15 PM, Dave Abrahams wrote: > > > on Tue Jun 07 2016, Matthew Johnson > wrote: > >>> On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> on Tue Jun

Re: [swift-evolution] Discussion: Why is "nil" not "none"

None would be similar to Null or nothing about the types in that sense which None is not a type. Nil would be interpret as Int, Float, String, etc On Wed, Jun 8, 2016 at 9:17 AM, Dany St-Amant via swift-evolution < swift-evolution@swift.org> wrote: > No clue as to the origins, but if you

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Jun 07 2016, Matthew Johnson wrote: > >>> , but haven't realized >>> that if you step around the type relationships encoded in Self >>> requirements

Re: [swift-evolution] Discussion: Why is "nil" not "none"

It depends how you frame it. When I see nil I think of 0 or a pointer. let someInt: Int? = nil Does someInt really have a value of 0? Is it really a pointer (because it looks like one). let someInt: Int? = none let someInt: Int? = .none - Doesn't look like a pointer and can't be

Re: [swift-evolution] Add a while clause to for loops

On Tue, Jun 7, 2016 at 6:26 PM, Tim Vermeulen wrote: > Interesting. What if you put newlines before `where` and `while`? It’s > hard to get the spacing right in a mailing list, but I tried it in Xcode > and it looks really good to me (except for the compiler error it currently

Re: [swift-evolution] Add a while clause to for loops

For most of of this discussion I have been for the introduction of 'while' and against the removal of 'where'; IMO, both help carry the intent of the code a bit better than the un-sugared version using if block (which can be mistaken for a regular condition) for number in fibonacci { if

Re: [swift-evolution] Discussion: Why is "nil" not "none"

That’s not quite what I meant. nil feels right to refer to an object-you can say “Foo is nil”, but you can’t really say that “Foo is none”, since while you can’t really use none as an adjective, as you can with nil. It’s really about what flows right-none is the opposite of some, but nil isn’t.

Re: [swift-evolution] Discussion: Why is "nil" not "none"

That's exactly the point I was going for. none makes more sense in this context than nil in my opinion Brandon > On Jun 7, 2016, at 8:10 PM, Saagar Jha wrote: > > Well, some is the opposite of none in that if I don’t have some, I have none. > nil is just a carry-over

Re: [swift-evolution] Discussion: Why is "nil" not "none"

Well, some is the opposite of none in that if I don’t have some, I have none. nil is just a carry-over from Objective-C. On Tue, Jun 7, 2016 at 5:07 PM Brandon Knope via swift-evolution < swift-evolution@swift.org> wrote: > I guess for me it comes down to this: > > *Why were some and none chosen

Re: [swift-evolution] Discussion: Why is "nil" not "none"

I guess for me it comes down to this: Why were some and none chosen for as the cases for Optional? As an extension of that, why does nil then represent none instead of the obvious none? There has to be a reason why it's not: enum Optional { case some(T) case nil } None seems a lot more

Re: [swift-evolution] [Returned for Revision] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

Yep. I also remain against this syntax, primarily for reasons of learnability. > On Jun 2, 2016, at 08:25, Austin Zheng via swift-evolution > wrote: > > I'm sure the list is getting sick of me making this point over and > over again :), so I'll only do it one more

Re: [swift-evolution] Discussion: Why is "nil" not "none"

There are NilLiteralConvertible types other than Optional, but they’re dwindling now that pointer nullability is represented by Optional. That said, I’m not convinced renaming “nil” is worth it at this point. Similarity with other languages is still a good thing. It’s true that we might not

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> But it’s *not* a type. The bottom type is as much a type as the top type (Any) is. There is a *lot* of literature on this. Respectfully, if you believe otherwise, you need to research type systems more until you change your mind. -- Brent Royal-Gordon Architechies

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> A return type makes a lot of sense linguistically but does not cover all > practical cases because you might not be the one deciding what the function's > signature is. For example, you might implement a protocol method that is > non-optional, but you never expect to be called. The only way

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

On 7 Jun, 2016, at 13:46, Thorsten Seitz wrote: >> Am 07.06.2016 um 20:11 schrieb Damien Sorresso via swift-evolution >> : >> >> On 7 Jun, 2016, at 09:47, Brent Royal-Gordon via swift-evolution >> wrote: I

Re: [swift-evolution] Add a while clause to for loops

Interesting. What if you put newlines before `where` and `while`? It’s hard to get the spacing right in a mailing list, but I tried it in Xcode and it looks really good to me (except for the compiler error it currently produces). Way better than the way I wrote it initially and the alternatives

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

on Tue Jun 07 2016, John McCall wrote: >> On Jun 5, 2016, at 5:18 PM, Dave Abrahams via swift-evolution >> wrote: >> on Thu Jun 02 2016, John McCall > > wrote: >> >>> The official way to build a literal

Re: [swift-evolution] Add a while clause to for loops

On Tue, Jun 7, 2016 at 5:11 PM, Tim Vermeulen wrote: > I’ve been thinking about this for a bit now, and I think it would make > most sense to evaluate these clauses from left to right. However, cases > where the order matters are very uncommon, and I would rather have the >

Re: [swift-evolution] Proposed changes to SE-0033 Import Objective-C Constants as Swift Types

> On Jun 6, 2016, at 3:51 PM, Ben Rimmington via swift-evolution > wrote: > > SE-0033 and SE-0044 are already "Implemented in Swift 3" according to both > the proposals and the README, but not according to the bug tracker: > >

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 4, 2016, at 11:54 AM, Chris Lattner wrote: > On Jun 2, 2016, at 9:08 AM, John McCall via swift-evolution > > wrote: >> >> The official way to build a literal of a specific type is to write the >> literal

Re: [swift-evolution] Add a while clause to for loops

I think `when` would be pretty confusing. If I didn’t know what it meant and I had to guess, I’d probably think that it means what `where` currently means. Calling it `while` could perhaps cause confusing with the while loop, but it means the same thing in both contexts so people might already

Re: [swift-evolution] Add a while clause to for loops

I’ve been thinking about this for a bit now, and I think it would make most sense to evaluate these clauses from left to right. However, cases where the order matters are very uncommon, and I would rather have the power to choose which clause is evaluated first than to have a forced default

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 7, 2016, at 3:56 PM, Xiaodi Wu wrote: > > No doubt, @noreturn is clearer today, but how much of that is because it's > what we already know? None. It’s clearer because it does exactly what it says on the tin. Show it to someone who’s familiar with the concept of

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

Ok, one last thing, then I go to sleep for today... Basic Definition of a "Type": I learned in university that a type is a "set of values". When a function has a return type of R, it means that it does return a value of type R. On the other hand, a @noreturn function doesn't return any value,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

on Tue Jun 07 2016, Matthew Johnson wrote: >> , but haven't realized >> that if you step around the type relationships encoded in Self >> requirements and associated types you end up with types that appear to >> interoperate but in fact trap at runtime unless used in

Re: [swift-evolution] Ad hoc enums / options

On Jun 7, 2016, at 2:49 PM, L Mihalkovic wrote: >> This is my favorite approach (assuming it's technically feasible) as it >> preserves the limitation that the enumerations are scoped strictly to the >> function but can be referenced outside of it. >> >> It allows

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

On Tue, Jun 7, 2016 at 3:57 PM, wrote: > > > Am 07.06.2016 um 22:36 schrieb Charles Srstka via swift-evolution < > swift-evolution@swift.org>: > > > >> On Jun 7, 2016, at 3:12 PM, Xiaodi Wu wrote: > >> > >> On Tue, Jun 7, 2016 at 2:49 PM, Michael

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> Am 07.06.2016 um 22:56 schrieb Xiaodi Wu via swift-evolution > : > > My response was simply to say that Never or NoReturn would in fact be a type, > which is a good justification for looking like one. This behavior would be > learnable and is theoretically sound,

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> Am 07.06.2016 um 22:36 schrieb Charles Srstka via swift-evolution > : > >> On Jun 7, 2016, at 3:12 PM, Xiaodi Wu wrote: >> >> On Tue, Jun 7, 2016 at 2:49 PM, Michael Peternell via swift-evolution >> wrote: >> >> >

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

On Tue, Jun 7, 2016 at 3:36 PM, Charles Srstka wrote: > On Jun 7, 2016, at 3:12 PM, Xiaodi Wu wrote: > > > On Tue, Jun 7, 2016 at 2:49 PM, Michael Peternell via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> > Am 07.06.2016 um 19:45

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 5, 2016, at 5:18 PM, Dave Abrahams via swift-evolution > wrote: > on Thu Jun 02 2016, John McCall > wrote: > >> The official way to build a literal of a specific type is to write the >> literal

Re: [swift-evolution] Ad hoc enums / options

> On Jun 7, 2016, at 10:29 PM, Erica Sadun via swift-evolution > wrote: > > >> On Jun 4, 2016, at 8:58 AM, Hooman Mehr > > wrote: >> >> How about this: >> >> >> Going back to Erica’s original example: >> >> func

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> Am 07.06.2016 um 20:11 schrieb Damien Sorresso via swift-evolution > : > > On 7 Jun, 2016, at 09:47, Brent Royal-Gordon via swift-evolution > wrote: >>> I disagree. We are discussing how to annotate a function in some way so >>> that

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> Am 07.06.2016 um 22:14 schrieb L Mihalkovic via swift-evolution > : > > >> On Jun 7, 2016, at 9:49 PM, Michael Peternell via swift-evolution >> wrote: >> >>> >>> Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> Am 01.06.2016 um 03:47 schrieb Xiaodi Wu via swift-evolution > : > > > > It does occur to me that there is one more option. I don't know that I like > it, but it's an option no one has put forward before: recite the opening > keyword when beginning a new boolean

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 7, 2016, at 3:12 PM, Xiaodi Wu wrote: > > On Tue, Jun 7, 2016 at 2:49 PM, Michael Peternell via swift-evolution > > wrote: > > > Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution > >

Re: [swift-evolution] Ad hoc enums / options

> On Jun 4, 2016, at 8:58 AM, Hooman Mehr wrote: > > How about this: > > > Going back to Erica’s original example: > > func scaleAndCropImage( > image: UIImage, > toSize size: CGSize, > operation: (.Fit | .Fill) = .Fit > ) -> UIImage { > > And noting that we

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> On Jun 7, 2016, at 9:47 PM, Thorsten Seitz wrote: > > > > Am 07.06.2016 um 20:11 schrieb L Mihalkovic via swift-evolution > >: > >> T1 === >> import Lib1 >> var str = func2()// lib1 >> >> T2 ===

Re: [swift-evolution] Add a while clause to for loops

On Tue, Jun 7, 2016 at 3:24 PM, Xiaodi Wu wrote: > It may be workable if you can have only one or the other, but mixing and > matching them as proposed above would be a world of hurt: > > ``` > for foo in bar where condition1 while condition2 { ... } > ``` > > If condition1

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

Actually that could cause more ambiguity if a type String is created inside ModuleA or ModuleB for example. So yeah, I think “from” keyword would be the best option actually. :( > On Jun 7, 2016, at 5:23 PM, Paulo Faria wrote: > > > >> Begin forwarded message: >> >> From:

Re: [swift-evolution] Add a while clause to for loops

It may be workable if you can have only one or the other, but mixing and matching them as proposed above would be a world of hurt: ``` for foo in bar where condition1 while condition2 { ... } ``` If condition1 and condition2 both evaluate to true, then whether you continue or break would depend

[swift-evolution] Fwd: Name disambiguation of computed property/function with same type defined in extensions

> Begin forwarded message: > > From: Paulo Faria > Subject: Re: [swift-evolution] Name disambiguation of computed > property/function with same type defined in extensions > Date: June 7, 2016 at 4:08:16 PM GMT-3 > To: Brent Royal-Gordon > > Yeah! I

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 7, 2016, at 9:49 PM, Michael Peternell via swift-evolution > wrote: > >> >> Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution >> : >> >>> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution >>>

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

On Tue, Jun 7, 2016 at 2:49 PM, Michael Peternell via swift-evolution < swift-evolution@swift.org> wrote: > > > Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution < > swift-evolution@swift.org>: > > > >> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution < >

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 7, 2016, at 12:49 PM, Michael Peternell via swift-evolution > wrote: > >> >> Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution >> : >> >>> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution >>>

Re: [swift-evolution] Add a while clause to for loops

On Tue, Jun 7, 2016 at 2:39 PM, Tim Vermeulen wrote: > > `while let element = sequence.next() where condition {…}` > > This is not a good alternative. First of all, it uses `while let` and > `next()` instead of `for … in` which is way more complex than necessary. > Also, if we

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution > : > >> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> I disagree. We are discussing how to annotate a function in some way so >>>

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> Am 07.06.2016 um 20:11 schrieb L Mihalkovic via swift-evolution > : > > T1 === > import Lib1 > var str = func2() // lib1 > > T2 === > import Lib1 > import func Lib2.func2 > var str = func2() // lib2 Shouldn't func2() be ambiguous here? It is

Re: [swift-evolution] Add a while clause to for loops

On Tue, Jun 7, 2016 at 2:16 PM, Tim Vermeulen wrote: > > The meaning of the proposed while is not at all a pair for where, since > where clauses in while loops would do the same thing as while clauses in > for loops. That's crazy. > > It sounds crazy, but it’s the nature of

Re: [swift-evolution] Add a while clause to for loops

> `while let element = sequence.next() where condition {…}` This is not a good alternative. First of all, it uses `while let` and `next()` instead of `for … in` which is way more complex than necessary. Also, if we want to skip over some elements, we either have to use `sequence.lazy.filter({

Re: [swift-evolution] Add a while clause to for loops

> On Jun 7, 2016, at 1:16 PM, Tim Vermeulen via swift-evolution > wrote: > >> The meaning of the proposed while is not at all a pair for where, since >> where clauses in while loops would do the same thing as while clauses in for >> loops. That's crazy. > > It

Re: [swift-evolution] Add a while clause to for loops

> The meaning of the proposed while is not at all a pair for where, since where > clauses in while loops would do the same thing as while clauses in for loops. > That's crazy. It sounds crazy, but it’s the nature of the while loop. A where clause in a while loop also has a different result

Re: [swift-evolution] [proposal] Allow function argument type to be omitted when passing a default value from which it can be inferred

yes, exactly Doug... the properties at type level are part of the interface and their types can be inferred, so i don't see the difference with function argument types. i just find it really bulky when writing something like this: func doSomething(thing, withManager: SomethingManager =

Re: [swift-evolution] Marking sort and sorted with rethrows

> True, but the cost of being able to restore the original ordering, when > that restoration may not be needed at all, is prohibitive. What about simply restoring the elements, in no particular order? This seems like an easy enough task, and I don’t think it requires the sorting algorithm to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 7, 2016, at 7:51 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Jun 07 2016, Matthew Johnson wrote: > >>> On Jun 6, 2016, at 12:22 AM, Dave Abrahams >> wrote: >>> >>> >>> on Sun Jun 05 2016, Matthew Johnson >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 7, 2016, at 12:51 PM, Dave Abrahams wrote: > > > on Tue Jun 07 2016, Matthew Johnson wrote: > >>> On Jun 6, 2016, at 12:22 AM, Dave Abrahams >> wrote: >>> >>> >>> on Sun Jun 05 2016, Matthew Johnson > >

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

and as you would expect … T4 === import Lib1 // importing EVERYTHING from lib1 import func Lib2.func2 // importing ONLY func2 from lib2 var int1 = func1() // 1 , because lib2::func2 is not ‘visible' —> showing again how extensions are treated

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

On 7 Jun, 2016, at 09:47, Brent Royal-Gordon via swift-evolution wrote: >> I disagree. We are discussing how to annotate a function in some way so that >> the compiler knows that the code following it will never be executed *and* >> so a human who reads the

Re: [swift-evolution] Marking sort and sorted with rethrows

on Tue Jun 07 2016, Saagar Jha wrote: > Exactly. While rethrows for sort make sense, since there is no user > variable modification, sortInPlace either needs to revert the array (which > is potentially expensive) or leave it in an arbitrary state, neither of > which are good choices. I can’t

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

T1 === import Lib1 var str = func2() // lib1 T2 === import Lib1 import func Lib2.func2 var str = func2() // lib2 T3 === import Lib1 import func Lib2.func2 var str = “str”.allCaps() // ERROR : ambiguous name Lib1 === public func func2() -> String { return

Re: [swift-evolution] Arrays Returning Optionals instead of Index Out of Bounds

Yes, thank you Jeremy for pointing on this, my fault :-(, was confused by initial description of the problem in proposal and in my fast test I got "Optional(nil)" in console for existed "nil" value in dict, but didn't realized that it should be printed just "nil". On 07.06.2016 19:06, Jeremy

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

on Tue Jun 07 2016, Matthew Johnson wrote: >> On Jun 6, 2016, at 12:22 AM, Dave Abrahams > wrote: >> >> >> on Sun Jun 05 2016, Matthew Johnson > wrote: >> > >>> Sent from my iPhone >>> On Jun 5, 2016, at 3:51 PM, Dave Abrahams

Re: [swift-evolution] Marking sort and sorted with rethrows

Exactly. While rethrows for sort make sense, since there is no user variable modification, sortInPlace either needs to revert the array (which is potentially expensive) or leave it in an arbitrary state, neither of which are good choices. I can’t seem to find any mutating function that rethrows,

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> I disagree. We are discussing how to annotate a function in some way so that >> the compiler knows that the code following it will never be executed *and* >> so a human who reads the

Re: [swift-evolution] Marking sort and sorted with rethrows

on Mon Jun 06 2016, Saagar Jha wrote: > Might I add that leaving an array in an arbitrary and > implementation-dependent state is also surprising to users as well as not > very useful-to the user this is nothing more than a random permutation. True, but the cost of being able to restore the

Re: [swift-evolution] Add a while clause to for loops

You're describing a while loop: `while let element = sequence.next() where condition {...}` Which as we've discussed can already be re-written with a for loop (which, yes, can be lazy): `for element in sequence.lazy.filter({ condition }) {...}` And it can be explicitly spelled out inside the

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> I disagree. We are discussing how to annotate a function in some way so that > the compiler knows that the code following it will never be executed *and* so > a human who reads the declaration knows that it does not return. “Never" is a > poor choice for that. Never what? Never return? Never

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> On Jun 7, 2016, at 11:36 AM, Paul Cantrell via swift-evolution > wrote: > >> >> On Jun 7, 2016, at 10:47 AM, L. Mihalkovic via swift-evolution >> > wrote: >> >> On Jun 7, 2016, at 4:53 PM, Tony

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> On Jun 7, 2016, at 10:47 AM, L. Mihalkovic via swift-evolution > wrote: > > On Jun 7, 2016, at 4:53 PM, Tony Allevato > wrote: > >> I like the "from" keyword the best, but I'll take my own stab at a >>

Re: [swift-evolution] [swift-corelibs-dev] [swift-users] WWDC Meetup

Hi David! No hard feelings at all :) I just wanted to propose something different, dinner sounds great! Thanks for setting that google forms up! On Tue, Jun 7, 2016 at 5:35 AM David Hart via swift-evolution < swift-evolution@swift.org> wrote: > Hi everybody, > > After receiving a private

Re: [swift-evolution] Arrays Returning Optionals instead of Index Out of Bounds

> IMO dictionary [Type1:Type2?] is a special case where you need to use > myDict.keys.contains(keyValue) first to determinate if you have a value for > key and after this you can get the value itself(which is Optional). I don’t understand why you think it is a special case. The return type of

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> On Jun 7, 2016, at 4:53 PM, Tony Allevato wrote: > > I like the "from" keyword the best, but I'll take my own stab at a > modification: > > import ModuleA > import ModuleB > > "hello world".(capitalized from ModuleA)() > "hello world".(capitalized from

Re: [swift-evolution] Arrays of optionals retuning optionals for all indicies

I think you're right Vladimir. After having this discussion I've changed my opinion on normal arrays returning optionals. I don't think that's a good idea as its not explicit and is unexpected behavior. I'd simply like to draft a proposal that has arrays of optionals returning optionals for

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

I like the "from" keyword the best, but I'll take my own stab at a modification: import ModuleA import ModuleB "hello world".(capitalized from ModuleA)() "hello world".(capitalized from ModuleB)() "hello world".(someProperty from ModuleA) "hello world".(someProperty from

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 6, 2016, at 12:22 AM, Dave Abrahams wrote: > > > on Sun Jun 05 2016, Matthew Johnson > wrote: > >> Sent from my iPhone >> >>> On Jun 5, 2016, at 3:51 PM, Dave Abrahams via swift-evolution >>> wrote:

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

+1 for NoReturn > Call it NoReturn as the comment you quoted suggests. > > If you want bottom types for other uses, give them their own appropriate and > self documenting names. > ___ > swift-evolution mailing list > swift-evolution@swift.org

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On 6 Jun 2016, at 16:37, Vladimir.S via swift-evolution > wrote: > > My opinion is based on this message: > > On 05.06.2016 23:16, L. Mihalkovic via swift-evolution wrote: > > > > FWIW, in the rejection of SE-0097 > >

Re: [swift-evolution] Arrays Returning Optionals instead of Index Out of Bounds

It seems like you are mixing two proposals: optional result of non-optional array and return value of optional array. I'm commenting the first - as it was already discussed earlier and based on community reaction on it - I believe it will not be supported again. Array is expected to fail fast

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

>> We already have the concept of prefixing a type name with a module to >> disambiguate when two modules have the same type. I wonder if we could do >> the same thing to disambiguate between conflicting extensions? >> >>import ModuleA >>import ModuleB >> >>("hello world" as

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> On Jun 7, 2016, at 7:09 AM, Charlie Monroe via swift-evolution > wrote: > >> We already have the concept of prefixing a type name with a module to >> disambiguate when two modules have the same type. I wonder if we could do >> the same thing to disambiguate

Re: [swift-evolution] Add a while clause to for loops

I give my +1 to this feature, it allows you to be explicit about a for loop escape condition at the outset instead of it being contained within the loops logic making them easier to maintain. Also it reads extremely well. > On Jun 7, 2016, at 5:20 AM, Vladimir.S via swift-evolution >

Re: [swift-evolution] Arrays Returning Optionals instead of Index Out of Bounds

Vladimir, thank you for pointing me to the discussion again. I read through the entire thing. And I didn't see a consensus around [Int?]. The main argument against was that it would allow the developer to be clumsy and remain unaware of a problem in the code because the choice is not explicit

Re: [swift-evolution] [swift-corelibs-dev] [swift-users] WWDC Meetup

Hi everybody, After receiving a private question, I'd like to clarify something: I’m hoping that anybody interested in the Swift Open Source project, contributor or not, WWDC ticket holder or not, should feel free to come! This is definitely not something I meant to be restricted in any way.

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

@escaping would be part of the parameter type just as @noescape is today. Your foo(closure:) example wouldn't compile with my proposal, the same as today if you marked the parameter with @noescape. Non-escaping function parameters are only allowed to be called. They can't be assigned to variables.

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> We already have the concept of prefixing a type name with a module to > disambiguate when two modules have the same type. I wonder if we could do the > same thing to disambiguate between conflicting extensions? > > import ModuleA > import ModuleB > > ("hello world" as

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

>> I want to discuss the problem of name ambiguity when a computed property or >> function is defined with the same name and type in different modules. >> Currently there’s no way to disambiguate the implementation in use cases >> similar to the one contained in the gist below. >> >>

Re: [swift-evolution] Arrays Returning Optionals instead of Index Out of Bounds

On 06.06.2016 21:02, Rob Norback wrote: First of all, thank you all for bringing me up to date so quickly. I looked over the proposal and it looks awesome. But as Chris mentioned, this doesn't solve the expected behavior and ambiguity of ```Array``` In this case I would expect the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> Le 31 mai 2016 à 21:47, Xiaodi Wu via swift-evolution > a écrit : > > Revisiting this conversation, it seems that most of the design space has been > thoroughly explored. I think all suggestions presented so far boil down to > these: > > Q: How is an arbitrary

Re: [swift-evolution] Add a while clause to for loops

I agree. `where` and `while` fit so well in for loops, IMO, because a for loop already loops over the elements - this is exactly what filter and prefix also do. You’ve even given the current element a name (for myElement in …) and it’s more natural to just use that name in a `where` clause or

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

> This proposal switches the default to be non-escaping and requires an > `@escaping` annotation if a closure argument can escape the function body. Is @escaping part of the function type syntax (like @autoclosure) or the parameter syntax (like inout)? It seems to me that there are places

  1   2   >