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

> Le 7 juin 2016 à 13:45, Charles Srstka via swift-evolution > a écrit : > >>> 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 i

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

> Le 8 juin 2016 à 02:21, Jordan Rose via swift-evolution > a écrit : > >> >> On Jun 7, 2016, at 12:49, Michael Peternell via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution >>> mailto:swift-evolution

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

>> The problem is, types flow through the type system. Use a NoReturn method >> with optional chaining, now you have an Optional. flatMap over >> that Optional, now you have a parameter of type NoReturn. What's a >> *parameter* of type NoReturn? You'd want it to be, say, a different bottom >> t

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

Sent from my iPad > On Jun 8, 2016, at 5:59 AM, Jeremy Pereira > wrote: > > >> On 8 Jun 2016, at 03:10, Brandon Knope via swift-evolution >> wrote: >> >> On the other hand... >> >> The first is rather clever and beautiful looking...making it somewhat Swifty. > > “Clever” is not necessari

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

Joe Groff wrote: > ## Impact on existing code > > The number of `@noreturn` functions in the wild is fairly small, and all of > them I can find return `Void`. It should be trivial to migrate > existing `@noreturn` functions to use `-> NoReturn`. Clang allows `_Noreturn` [C11] and `__attribute__((

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

> On 8 Jun 2016, at 03:10, Brandon Knope via swift-evolution > wrote: > > On the other hand... > > The first is rather clever and beautiful looking...making it somewhat Swifty. “Clever” is not necessarily good. “Clever” implies cleverness is needed to understand it. “Beautiful” is a subje

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

> On 7 Jun 2016, at 17:47, Brent Royal-Gordon 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 declaration knows that it does not return. “Never" >

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

By Void I meant Haskell's Void, or Swift's Never type. Swift's Void is Haskell's (). And I had an error there. Integer -> Void contains two elements: a function that always returns _|_, and an _|_. In Swift, the first case corresponds to crash while executing function, and second case corresponds

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

> On Jun 8, 2016, at 10:28 AM, Антон Жилин via swift-evolution > wrote: > > I'll talk about how "bottom" mechanic works there. (I'm not a Haskell expert, > but I'll at least try ;) ) > > Firstly, there is a Void type in standard library, which is exactly what > enum Never {} in Swift is. >

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

I'll talk about how "bottom" mechanic works there. (I'm not a Haskell expert, but I'll at least try ;) ) Firstly, there is a Void type in standard library, which is exactly what enum Never {} in Swift is. Pretty trivial: it is useful as a parameter of higher kinded types, e.g. Either. Then, the

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

+1 for the bottom type > On 08 Jun 2016, at 07:45, L Mihalkovic via swift-evolution > wrote: > > >> 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

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

> On Jun 8, 2016, at 7:49 AM, L Mihalkovic wrote: > >> >> 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

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 TypeSc

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. > > I hope that Swift w

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 might implement a protocol met

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 is a type with an empty set

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

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. I hope that Swift will someday have variance annotations for generic parameters and a

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

On the other hand... The first is rather clever and beautiful looking...making it somewhat Swifty. I never cared for annotations: - they make it look noisy - they seem like a "hack" rather than a true part of the standard library Also technically, @noreturn func fatalError() can be modeled

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

> On Jun 7, 2016, at 7:21 PM, Jordan Rose via swift-evolution > wrote: > > >>> On Jun 7, 2016, at 12:49, 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 Roy

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

> On Jun 7, 2016, at 12:49, 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 >>> wrote: >>> I disagree. We are discussing how to ann

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 to

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 disagree. We are discussing how to annotate a function in some way so that th

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 functions and returnin

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

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 Peternell via swift-evolution < > swift-evolution

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, not an ad hoc idea being mad

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: >> >> > Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution >> > : >

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 schrieb Charles Srstka via swift-evolution < >>

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 the compiler knows that the code following it will never

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 >>> : >>> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gor

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 > mailto:swift-evolution@swift.org>> wrote: > > > Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution > > mailto:swift-evolution@swift.org>>: > > > >> On Jun 7

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 >>> wrote: >>> I disagree. We are discussing how to a

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

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 >>> wrote: >>> I disagree. We are discussing how to

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 >>> that the compiler knows that the code following it wil

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 declaration knows that it does not re

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 declaration knows that it d

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 u

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] [Draft] Change @noreturn to unconstructible return type

> E.g. with the proposal, the following function: > > @noreturn func error(msg: String = "") -> T { >fatalError("bottom: \(msg)") > } > > has to be written as > > func error(msg: String = "") -> T { >fatalError("bottom: \(msg)") > } > > It still returns bottom, but there is no way to sa

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

> > @noreturn func error(msg: String = "") -> T { > fatalError("bottom: \(msg)") > } > has to be written as > func error(msg: String = "") -> T { > fatalError("bottom: \(msg)") > } > It still returns bottom, but there is no way to say so in the declaration. > The proposal just made the lang

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

> On 06 Jun 2016, at 22:40, Michael Peternell via swift-evolution > wrote: > > E.g. with the proposal, the following function: > > @noreturn func error(msg: String = "") -> T { >fatalError("bottom: \(msg)") > } > > has to be written as > > func error(msg: String = "") -> T { >fatalEr

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

> Am 06.06.2016 um 00:53 schrieb Charles Srstka : > >> On Jun 5, 2016, at 5:41 PM, Michael Peternell via swift-evolution >> wrote: >> >>> Am 05.06.2016 um 20:26 schrieb Антон Жилин via swift-evolution >>> : >>> >>> The following names were suggested: NoReturn, Bottom, None, Never. >>> I woul

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

Ceylon demonstrates other uses for the bottom type than just marking @noreturn methods, e.g. (mixing Ceylon and Swift syntax freely here) class Iterable { var last: Element | Absent // remember that optionals in Ceylon are modeled as union type T | Null ... } Iterable // a

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

What about `PreconditionFailure`? If you obtain an instance of this type, it means a precondition has failed. Jacob On Mon, Jun 6, 2016 at 9:48 AM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > `Never` seems reasonable to me too. I'll add that to the proposal as an > altern

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

`Never` seems reasonable to me too. I'll add that to the proposal as an alternative. -Joe > On Jun 5, 2016, at 11:37 AM, T.J. Usiyan via swift-evolution > wrote: > > I vote for Bottom or Never. None does not convey "this should not occur or be > evaluated". > > On Sun, Jun 5, 2016 at 2:26 P

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

IMHO there is a deep relationship between this discussion, 0092 and a serie of other recent topics (like literal convertibles or the extended existentials). There is no doubt that these questions must and will all be answered individually, however it is my HO that there is a small window of time

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

On Mon, Jun 6, 2016 at 10:39 AM, Charlie Monroe via swift-evolution < swift-evolution@swift.org> wrote: > I'd argue that it's more important for the language to be clearly readable > than to satisfy a notion of absolute adherence to pure formal semantics > that only theorists would completely unde

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

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 > , > this was what the core team had to say about it: > > /1) For nor

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

> I'd argue that it's more important for the language to be clearly readable > than to satisfy a notion of absolute adherence to pure formal semantics that > only theorists would completely understand. The semantics might help a person better understand the philosophy of the language. The @nore

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

"Nothing" feels like it collides too much with the concept of a function that returns, but returns nothing (i.e., Void), however. If I read a function declaration from left to right: func foo() -> Nothing I read that as "a function foo that returns nothing". That sounds like a Void function

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

You are thinking of it as a return type, but that's not how you should think of it, really - that's an example of what it may be used for, but it should not be the only aspect. It should be the opposite of Any, which (excluding None), seems to be Nothing. Or Singularity :) 6. 6. 2016 v 16:12,

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

+1 for Never, as 'foo() -> Never' reads as 'foo returns never' i.e. close to 'never returns'. Or we just need NoReturn as replacement for @noreturn, and then think about true bottom type and its name separately. On 06.06.2016 16:37, Thorsten Seitz via swift-evolution wrote: My preference from

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

My preference from the current suggestions would be Never. -Thorsten > Am 06.06.2016 um 15:24 schrieb Thorsten Seitz via swift-evolution > : > > Ceylon uses `Nothing` for the bottom type. > > -Thorsten > >> Am 05.06.2016 um 20:39 schrieb Charlie Monroe via swift-evolution >> : >> >> While

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

Ceylon uses `Nothing` for the bottom type. -Thorsten > Am 05.06.2016 um 20:39 schrieb Charlie Monroe via swift-evolution > : > > While None is probably the best way to describe the opposite of Any, it would > be often mistaken for .None (i.e. Optional) by newcomers to the language. > > I'd p

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

>> This is a language that has put protocol centerstage. It stands to reason >> express something as essential using a protocol. >> >> protocol Nothing {} >> >> seems more than rational > > No, this doesn't make sense as a protocol. You should not be able to conform > to Nothing, but you c

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

> Why? The compiler flags an error if it can statically prove a trapping overflow will occur. Why shouldn't it flag an error if it can statically prove a force unwrap will fail? > If one of the associated values is Bottom/None/Never, how is my code improved by the fact that I still need a case for

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

> Bringing up an old idea, we could rewrite `rethrows` using Never and throws > type specification: > > func call(block: () throws E -> T) throws E -> T > > But this requires some compiler magic: non-throwing functions should > effectively become functions throwing Never. This is very clever,

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

> This is a language that has put protocol centerstage. It stands to reason > express something as essential using a protocol. > > protocol Nothing {} > > seems more than rational No, this doesn't make sense as a protocol. You should not be able to conform to Nothing, but you could conform

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

> I'd personally prefer calling it "Nil" (capital N), which really means > "nonexistent". The same way ObjC had "nil" for "id" and "Nil" for Class. > Possibly, to avoid confusion with nil, calling it Null? Though that might get > confused with NSNull, once the NS prefix gets dropped. I don't th

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

> The following names were suggested: NoReturn, Bottom, None, Never. > I would pick None, because it looks like opposite to Any and fits nicely in > generic types. I discussed all of these options and more. The issue I see with None is that it could easily be interpreted as Void to those without

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

> On Jun 6, 2016, at 8:25 AM, David Hart via swift-evolution > wrote: > > I'm against using Nil as it would have a very different meaning than Nil (or > Null) in all other C-based languages. Well said :) >> On 06 Jun 2016, at 05:56, Charlie Monroe via swift-evolution >> wrote: >> >> Addin

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

I'm against using Nil as it would have a very different meaning than Nil (or Null) in all other C-based languages. > On 06 Jun 2016, at 05:56, Charlie Monroe via swift-evolution > wrote: > > Adding a Nil *type* is a bit different than casting dozen of identifiers to > (void*)0... > >> On Jun

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

Adding a Nil *type* is a bit different than casting dozen of identifiers to (void*)0... > On Jun 5, 2016, at 10:54 PM, T.J. Usiyan wrote: > > *please* let us not repeat the mostly avoidable > challenging-to-explain-to-newcomers-and-vetarans-alike situation that we had > in Obj-C with regard t

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

Bringing up an old idea, we could rewrite `rethrows` using Never and throws type specification: func call(block: () throws E -> T) throws E -> T But this requires some compiler magic: non-throwing functions should effectively become functions throwing Never. - Anton 2016-06-06 1:53 GMT+03:00 Ch

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

> On Jun 5, 2016, at 5:41 PM, Michael Peternell via swift-evolution > wrote: > >> Am 05.06.2016 um 20:26 schrieb Антон Жилин via swift-evolution >> mailto:swift-evolution@swift.org>>: >> >> The following names were suggested: NoReturn, Bottom, None, Never. >> I would pick None, because it look

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

> Am 05.06.2016 um 20:26 schrieb Антон Жилин via swift-evolution > : > > The following names were suggested: NoReturn, Bottom, None, Never. > I would pick None, because it looks like opposite to Any and fits nicely in > generic types. I would like to call the type `Void`. `Void` is a type with

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

I have to agree with Never. None is for Optional.none, and it looks like Void in function signature. I would argue that Never could not be mistaken as a synonym for Void. protocol Nothing {} is exactly how Any could be defined, so it's an opposite entity. We could define that as a protocol that no

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

*please* let us not repeat the mostly avoidable challenging-to-explain-to-newcomers-and-vetarans-alike situation that we had in Obj-C with regard to `nil`. nil Nil NULL NSNull nullptr kCFNull __DARWIN_NULL are the representations of 'don't have' that come to mind. On Sun, Jun 5, 2016 at 2:39 P

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

> On Jun 5, 2016, at 9:47 PM, Pyry Jahkola via swift-evolution > wrote: > I would prefer the type to be simple, and be implemented as a case-less enum (not a bottom value, as in Haskell). None should be a usual enum, with no compiler magic except that functions retu

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

>>> I would prefer the type to be simple, and be implemented as a case-less >>> enum (not a bottom value, as in Haskell). >>> >>> None should be a usual enum, with no compiler magic except that functions >>> returning None are equivalent to current @noreturn. >> >> I think it would be more usef

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

> On Jun 5, 2016, at 8:39 PM, Charlie Monroe via swift-evolution > wrote: > > While None is probably the best way to describe the opposite of Any, it would > be often mistaken for .None (i.e. Optional) by newcomers to the language. > > I'd personally prefer calling it "Nil" (capital N), whic

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

> On Jun 5, 2016, at 1:49 PM, Pyry Jahkola via swift-evolution > wrote: > > >> On 05 Jun 2016, at 21:26, Антон Жилин via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> The following names were suggested: NoReturn, Bottom, None, Never. >> I would pick None, because it looks

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

> On 05 Jun 2016, at 21:26, Антон Жилин via swift-evolution > wrote: > > The following names were suggested: NoReturn, Bottom, None, Never. > I would pick None, because it looks like opposite to Any and fits nicely in > generic types. I would pick `Never` because `None` would overload the not

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

While None is probably the best way to describe the opposite of Any, it would be often mistaken for .None (i.e. Optional) by newcomers to the language. I'd personally prefer calling it "Nil" (capital N), which really means "nonexistent". The same way ObjC had "nil" for "id" and "Nil" for Class.

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

I vote for Bottom or Never. None does not convey "this should not occur or be evaluated". On Sun, Jun 5, 2016 at 2:26 PM, Антон Жилин wrote: > The following names were suggested: NoReturn, Bottom, None, Never. > I would pick None, because it looks like opposite to Any and fits nicely > in generi

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

The following names were suggested: NoReturn, Bottom, None, Never. I would pick None, because it looks like opposite to Any and fits nicely in generic types. I would prefer the type to be simple, and be implemented as a case-less enum (not a bottom value, as in Haskell). None should be a usual en