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

[Jean-Daniel Dupas via swift-evolution]

> 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 
>> > 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 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 use 
> this function? Never say never again? 
 
 "Never return". That's why it's in the return type slot, right after the 
 `->`. If you read it out loud, you'll read "returns Never", which is 
 exactly correct.
 
 NoReturn, on the other hand, does *not* read well in that slot: "returns 
 NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it makes 
 no sense whatsoever *as a type name*.
>>> 
>>> But it’s *not* a type. You’ll never have an instance of it. Since it’s not 
>>> a type name, it doesn’t make sense that it needs to look like one. What it 
>>> is doing is telling you something about the behavior of the function 
>>> itself, not its return value. Its return value, if there were one, is 
>>> irrelevant, since the function, by its very nature, will never even get to 
>>> the point where it would return it. Either it’s going to kill the app via a 
>>> fatalError or something, or we have something like dispatch_main() which 
>>> will keep executing until the program stops, and one way or another, it 
>>> won’t return.
>>> 
>>> For that reason, frankly, I don’t understand why we want to change this 
>>> from being an attribute, which seems to me the more natural and logical 
>>> choice to describe this behavior. If we *do* have to change it, though, 
>>> NoReturn conveys the most clearly to the reader what it does.
>> 
>> +1 for @noreturn
>> We don't have to change it.
>> We have to keep it.
> 
> I strongly agree. Just because it can be modelled as a type doesn’t mean it’s 
> the best way to represent the concept. It feels like uniformity for 
> uniformity’s sake.
> 
> func fatalError() -> Never
> 
> @noreturn func fatalError()
> 
> The first one probably isn't too hard to explain to a learner. The second one 
> probably doesn’t need an explanation.

+1 for keeping it as it is for the same arguments and many other arguments 
already details previously, like telling the function can return something that 
does not exists is not the same that telling it does not return or the fact 
that you can’t expect to code it purely in the standard library using type if 
you want to be able to warn on unreachable code let the compiler optimize based 
on the fact the function never returns (and does not return never).


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

>> 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 
>> type named NoPass, but you can't—the type came from a NoReturn, and it's 
>> stuck being a NoReturn.
> 
> This is a method that *does not return*. The compiler should error if you try 
> to use the “result” of a no return function. In fact, it should error if 
> there is any more code after the method that can’t be reached by a path that 
> avoids the call.

Like the path introduced by optional chaining, which I *specifically* mentioned 
in the paragraph you quoted so scathingly.

Let me write out an example explicitly so you can see what I mean. Suppose you 
have this protocol:

protocol Runnable {
associatedtype Result
func run() -> Result
static func isSuccessful(_ result: Result) -> Bool
}

And you implement this generic function to use it:

func runAndCheck(_ runner: R?) -> Bool {
return runner?.run().flatMap(R.isSuccessful) ?? true
}

With intermediate variables and explicit type annotations, that's:

func runAndCheck(_ runner: R?) -> Bool {
let optionalResult: R.Result? = runner?.run()
let optionalSuccess: Bool? = 
processedResult.flatMap(R.isSuccessful)
let success: Bool = optionalSuccess ?? true
return success
}

Now, suppose `R` is a `RunLoop` type with a `run()` method that never returns. 
(`NSRunLoop` is similar to this type, although its `run()` actually can return; 
you just can't really count on it ever doing so.) Then you have this:

class RunLoop: Runnable {
…
associatedtype Result = Never

func run() -> Never {
…
}

class func isSuccessful(_ result: Never) -> Bool {
// Uncallable due to Never parameter
}
}

And `runAndCheck(_:)` specializes to:

func runAndCheck(_ runner: RunLoop?) -> Bool {
let optionalResult: Never? = runner?.run()
let optionalSuccess: Bool? = 
processedResult.flatMap(RunLoop.isSuccessful)
let success: Bool = optionalSuccess ?? true
return success
}

So, as you can see, this code *does* have a path beyond the non-returning call: 
the path where `runner` is `nil`.

This code benefits in several ways from using a bottom type to express 
`run()`'s non-returning nature:

1. The protocol now correctly expresses the fact that, if `run()` can never 
return, then `isSuccessful(_:)` can never be called. With a `@noreturn` 
attribute, `run()` would have to have some kind of fake return type (probably 
`Void`), and `isSuccessful` would be callable with a `Void`.

2. Because the compiler can prove that `isSuccessful(_:)` can never be called, 
there's no need to provide any implementation for it. The compiler can prove 
that any implementation you might provide is dead code, because it could only 
be reached after code that would have to instantiate a `Never`. With a 
`@noreturn` attribute, `Result` would be some fake type like `Void`, and the 
compiler could not prove that `isSuccessful(_:)` is unreachable.

3. Since `optionalResult` is of type `Never?`, the compiler can prove that it 
cannot ever be `.some`. To construct a `.some`, you would need to instantiate a 
`Never`, which is impossible. With a `@noreturn`-type solution, 
`optionalResult` would be of (say) type `Void?`, and the fact that `.some` was 
impossible would be lost to us.

This means that:

1. If the compiler inlines `Optional.flatMap`, it can eliminate the 
`.some` case (since it can never match), then eliminate the `switch` statement 
entirely, turning the method into simply `return .none`.

func runAndCheck(_ runner: RunLoop?) -> Bool {
let optionalResult: Never? = runner?.run()
let optionalSuccess: Bool? = .none
let success: Bool = optionalSuccess ?? true
return success
}

2. The compiler can then notice that `optionalSuccess` is always `.none`, so 
`success` is always `true`.

func runAndCheck(_ runner: RunLoop?) -> Bool {
let optionalResult: Never? = runner?.run()
let success: Bool = true
return success
}

3. The compiler can then notice that `optionalResult` is never actually used, 
and eliminate that value.

func runAndCheck(_ runner: RunLoop?) -> Bool {
_ = runner?.run()
let success: Bool = true
return success
}

Could the compiler have done this without using `Never`? 

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

[Brandon Knope via swift-evolution]

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 necessarily good. “Clever” implies cleverness is needed to 
> understand it. 

I knew I would regret using this word. I can do this too: "clever" is not 
necessarily bad either. (The very definition says "quick to understand, 
learn...". Seems pretty apt here)

> “Beautiful” is a subjective concept. Personally, I think a computer language 
> construct is beautiful if it conveys the intent with complete clarity. By my 
> criteria the @noreturn attribute is beautiful and the -> Never return type is 
> ugly (or at least less beautiful).

Of course it is subjective. Almost every reply in swift evolution is rooted in 
personal opinion. 

> “Swifty” is a nebulous concept that nobody has defined and thus means 
> different things to different people. It seems to me that “it’s not Swifty” 
> is used mostly to try to shut down debate when reasoned arguments are thin on 
> the ground.  

I guess we need to tell this to Chris...who uses it quite often. "Swifty" IS a 
thing. It's just not 100% defined and constantly changing. 
> 
>> 
>> I never cared for annotations:
> 
> That’s a subjective opinion.

Of course...but isn't this where I share...my opinion?

> 
>> - they make it look noisy
> 
> How so?

@noreturn func test() -> Void
func test() -> Never

Objectively...it is less noisy by using less characters :P. 

Also, the function information seems somewhat lost with the heavy @ annotation 
(my opinion!). My eyes are immediately drawn to the annotation when looking at 
this signature. Is this good or bad? It's all subjective, but to me it makes 
this version noisier. 


> 
>> - they seem like a "hack" rather than a true part of the standard library
> 
> Annotations aren’t part of the standard library are they? I thought they were 
> part of the language.

That was kind of my point. Doesn't swift try to define almost everything in the 
standard library? It would be more Swifty!
> 
>> 
>> Also technically, 
>> 
>> @noreturn func fatalError()
>> 
>> can be modeled as (I think?):
>> @noreturn func fatalError() -> Void
>> 
>> which doesn't make much sense.
> 
> In what way does it not make sense? Theoretically there’s no problem with 
> specifying a return type for a noreturn function.

It's redundant. And why would a noreturn function have a return type? Maybe I'm 
missing a use case


> 
>> 
>> Also, could this fix this issue:
>> "That said, you can’t override a function or method that is marked with the 
>> noreturnattribute with a function or method that is not. Similar rules apply 
>> when you implement a protocol method in a conforming type."
>> 
>> Overriding a method without this as an attribute could allow this. I'm not 
>> sure if this is something people would need though or if it even makes sense.
> 
> It doesn’t make sense. If you have a protocol or a base class with an 
> @noreturn method, and you could override it with a method that does return, 
> then code using the protocol or base class that assumes that the method does 
> not return as the API contract says will be surprised when, after dispatching 
> the call, it returns.
> 

This one was a stretch on my part, but I need to think a little more on this. 

Brandon 

> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Rimmington via swift-evolution]

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__((noreturn))` [GCC] functions
to have a non-void return type.

NSApplicationMain and UIApplicationMain have an integer return type, but they
never return. (There might be similar functions in other libraries). If these
functions could add `_Noreturn` without breaking binary compatibility, should
SE-0102 be rejected?

> ### Naming `NoReturn`
>
> The best name for the standard library uninhabited type is up for debate.
> `NoReturn` seems to me like the name most immediately obvious to most users
> compared to these alternatives:

Would an `Unreachable` type name match the SIL and Clang terms?




If empty "ad hoc enums" were available, you wouldn't need to choose a name!



Off-topic:

* Could "incomplete struct types" also be imported as empty enums?
* Would the Swift.OpaquePointer then become a generic type?

-- Ben


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jeremy Pereira via swift-evolution]

> 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" 
>> is a poor choice for that. Never what? Never return? Never use this 
>> function? Never say never again? 
> 
> "Never return". That's why it's in the return type slot, right after the 
> `->`. If you read it out loud, you'll read "returns Never", which is exactly 
> correct.

I would read it as “returns an object of type “Never” if I hadn’t been reading 
this thread. “Never" is a bad choice if all you want to do is indicate to a 
human that the function does not return. 


> 
> NoReturn, on the other hand, does *not* read well in that slot: "returns 
> NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it makes no 
> sense whatsoever *as a type name*.

Who cares? We want it to be as obvious as possible that the function does not 
return not that the construct reads like an English sentence.

> 
>> If you want bottom types for other uses, give them their own appropriate and 
>> self documenting names. 
> 
> 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 
> type named NoPass, but you can't—the type came from a NoReturn, and it's 
> stuck being a NoReturn.

This is a method that *does not return*. The compiler should error if you try 
to use the “result” of a no return function. In fact, it should error if there 
is any more code after the method that can’t be reached by a path that avoids 
the call.

I think you have convinced me that the idea of indicating noreturn methods with 
a return type is pretty stupid.

> 
> Never works pretty well—honestly, surprisingly well—in all of these contexts.

It might do logically and from the ivory tower purist point of view, but for a 
casual reader of the code who just wants to understand the API 

@noreturn func foo()

is vastly superior to 

   func foo() -> Never



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Антон Жилин via swift-evolution]

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
to crash while computing a result of function type.

- Anton

2016-06-08 11:28 GMT+03:00 Антон Жилин :

> 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, there is bottom. Long story short, each type in Haskell includes an
> undefined (bottom, _|_) value. That corresponds to partially defined
> functions in set theory.
>
> Example 1: Integer -> Integer  function can either return a Z number, or
> be undefined at that input (return bottom)
> Example 2: ()  type actually contains two elements: () and _|_
> Example 3: Void  contains one element: _|_
>
> Bottom value results in an error on most occasions.
>
> What does returning Void mean? In set theory, set of  Integer -> Void  is
> an empty set. In type theory,  Integer -> Void  can contain a single
> element that returns bottom.
>
> Applying that to Swift, we express bottom value by not returning on a
> particular input (due to a crash or an infinite loop). We are going to
> express bottom type by Never (or aliases). The only way to return bottom
> type is as well going to be returning bottom value (in Swift meaning).
>
> There is also such a function in Haskell:  absurd :: forall a. Void -> a
> Of course, it just returns bottom value of type a. The philosophy of this
> is "from false follows anything" or like, "if we are going to crash, then
> we can do anything".
> Based on this, we can implement conversions from Void to any type in
> Swift. It would look like:
>
> func implementContract() -> Int {
> return fatalError("unimplemented")
> }
>
> `return` is crucial here.
> This is what I suggest to change in the proposal.
>
> - Anton
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

> 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.
> Pretty trivial: it is useful as a parameter of higher kinded types, e.g. 
> Either.

Not really. Void is a "Unit" type - it's not an empty enum, it's an enum with 
exactly one value. The set of values for the Void type contains exactly one 
possible value.

> 
> Then, there is bottom. Long story short, each type in Haskell includes an 
> undefined (bottom, _|_) value. That corresponds to partially defined 
> functions in set theory.
> 
> Example 1: Integer -> Integer  function can either return a Z number, or be 
> undefined at that input (return bottom)
> Example 2: ()  type actually contains two elements: () and _|_
> Example 3: Void  contains one element: _|_
> 
> Bottom value results in an error on most occasions.
> 
> What does returning Void mean? In set theory, set of  Integer -> Void  is an 
> empty set. In type theory,  Integer -> Void  can contain a single element 
> that returns bottom.
> 
> Applying that to Swift, we express bottom value by not returning on a 
> particular input (due to a crash or an infinite loop). We are going to 
> express bottom type by Never (or aliases). The only way to return bottom type 
> is as well going to be returning bottom value (in Swift meaning).
> 
> There is also such a function in Haskell:  absurd :: forall a. Void -> a
> Of course, it just returns bottom value of type a. The philosophy of this is 
> "from false follows anything" or like, "if we are going to crash, then we can 
> do anything".
> Based on this, we can implement conversions from Void to any type in Swift. 
> It would look like:
> 
> func implementContract() -> Int {
> return fatalError("unimplemented")
> }
> 
> `return` is crucial here.
> This is what I suggest to change in the proposal.
> 
> - Anton
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Антон Жилин via swift-evolution]

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, there is bottom. Long story short, each type in Haskell includes an
undefined (bottom, _|_) value. That corresponds to partially defined
functions in set theory.

Example 1: Integer -> Integer  function can either return a Z number, or be
undefined at that input (return bottom)
Example 2: ()  type actually contains two elements: () and _|_
Example 3: Void  contains one element: _|_

Bottom value results in an error on most occasions.

What does returning Void mean? In set theory, set of  Integer -> Void  is
an empty set. In type theory,  Integer -> Void  can contain a single
element that returns bottom.

Applying that to Swift, we express bottom value by not returning on a
particular input (due to a crash or an infinite loop). We are going to
express bottom type by Never (or aliases). The only way to return bottom
type is as well going to be returning bottom value (in Swift meaning).

There is also such a function in Haskell:  absurd :: forall a. Void -> a
Of course, it just returns bottom value of type a. The philosophy of this
is "from false follows anything" or like, "if we are going to crash, then
we can do anything".
Based on this, we can implement conversions from Void to any type in Swift.
It would look like:

func implementContract() -> Int {
return fatalError("unimplemented")
}

`return` is crucial here.
This is what I suggest to change in the proposal.

- Anton
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

+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 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 associated types so that we may express sound subtyping rules 
>> between generic types. A real bottom type will fit in there just nicely.
>> 
>> +1 for a real bottom type
>> +1 for calling it Never
> 
> +1 on all accounts (it is not the first time I find myself in agreement with 
> many of the choices you support, and more interestingly, with the rational 
> you use to support them: usually a mix between references to other examples 
> and pragmatism).
> 
> here is another twist on Never… see further down...
> 
> 
>> 
>> -Thorsten 
>> 
>> 
 Am 07.06.2016 um 22:43 schrieb Michael Peternell via swift-evolution 
 :
 
 
 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-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 return. “Never" is a poor choice for that. Never what? Never 
 return? Never use this function? Never say never again?
>>> 
>>> "Never return". That's why it's in the return type slot, right after 
>>> the `->`. If you read it out loud, you'll read "returns Never", which 
>>> is exactly correct.
>>> 
>>> NoReturn, on the other hand, does *not* read well in that slot: 
>>> "returns NoReturn". Huh? I mean, I suppose you won't misunderstand it, 
>>> but it makes no sense whatsoever *as a type name*.
>> 
>> But it’s *not* a type. You’ll never have an instance of it. Since it’s 
>> not a type name, it doesn’t make sense that it needs to look like one. 
>> What it is doing is telling you something about the behavior of the 
>> function itself, not its return value. Its return value, if there were 
>> one, is irrelevant, since the function, by its very nature, will never 
>> even get to the point where it would return it. Either it’s going to 
>> kill the app via a fatalError or something, or we have something like 
>> dispatch_main() which will keep executing until the program stops, and 
>> one way or another, it won’t return.
>> 
>> For that reason, frankly, I don’t understand why we want to change this 
>> from being an attribute, which seems to me the more natural and logical 
>> choice to describe this behavior. If we *do* have to change it, though, 
>> NoReturn conveys the most clearly to the reader what it does.
> 
> +1 for @noreturn
> We don't have to change it.
> We have to keep it.
 
 
 this is so unfortunate… IMHO the proposal is the right move because it 
 goes into the direction of unifying things in the language. the problem is 
 that it is difficult to see it without looking at the language as a whole. 
 then we realize that this can be connected to the change of dynamicType to 
 a function or to the fact that .Type and .Self might also warrant a 
 revisiting.
>>> 
>>> from a practical point of view, a @noreturn function is just so much 
>>> different than any other function. this shouldn't be "unified". we can 
>>> discuss if bottom types and normal types can be unified from a 
>>> theoretical/academical point of view. but in the real world, a @noreturn 
>>> function does not return at all, whereas most other function does return 
>>> execution to its caller. To honor this view, a function that returns `Void` 
>>> is meant to return, it just doesn't return any particular value. But `Void` 
>>> should be the type with no values, not the type with exactly one value, so 
>>> a function that returns `Void` shouldn't be able to return, because there 
>>> can be no `Void` value. `Void` is an unconstructable type, and yet it is 
>>> different from `@noreturn`. That would be a unification ;) . The whole 
>>> concept of return-values is so much different in imperative programming 
>>> than it is in Haskell and with "denotational semantics". Therefore 

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

[L Mihalkovic via swift-evolution]

> 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 type 
>> systems of other languages like Ceylon, Rust or TypeScript.
>> 
>> I hope that Swift will someday have variance annotations for generic 
>> parameters and associated types so that we may express sound subtyping rules 
>> between generic types. A real bottom type will fit in there just nicely.
>> 
>> +1 for a real bottom type
>> +1 for calling it Never
> 
> +1 on all accounts (it is not the first time I find myself in agreement with 
> many of the choices you support, and more interestingly, with the rational 
> you use to support them: usually a mix between references to other examples 
> and pragmatism).
> 
> here is another twist on Never… see further down...
> 
> 
>> 
>> -Thorsten 
>> 
>> 
>>> Am 07.06.2016 um 22:43 schrieb Michael Peternell via swift-evolution 
>>> >:
>>> 
>>> 
 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-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 return. “Never" is a poor choice for that. Never what? Never 
 return? Never use this function? Never say never again?
>>> 
>>> "Never return". That's why it's in the return type slot, right after 
>>> the `->`. If you read it out loud, you'll read "returns Never", which 
>>> is exactly correct.
>>> 
>>> NoReturn, on the other hand, does *not* read well in that slot: 
>>> "returns NoReturn". Huh? I mean, I suppose you won't misunderstand it, 
>>> but it makes no sense whatsoever *as a type name*.
>> 
>> But it’s *not* a type. You’ll never have an instance of it. Since it’s 
>> not a type name, it doesn’t make sense that it needs to look like one. 
>> What it is doing is telling you something about the behavior of the 
>> function itself, not its return value. Its return value, if there were 
>> one, is irrelevant, since the function, by its very nature, will never 
>> even get to the point where it would return it. Either it’s going to 
>> kill the app via a fatalError or something, or we have something like 
>> dispatch_main() which will keep executing until the program stops, and 
>> one way or another, it won’t return.
>> 
>> For that reason, frankly, I don’t understand why we want to change this 
>> from being an attribute, which seems to me the more natural and logical 
>> choice to describe this behavior. If we *do* have to change it, though, 
>> NoReturn conveys the most clearly to the reader what it does.
> 
> +1 for @noreturn
> We don't have to change it.
> We have to keep it.
 
 
 this is so unfortunate… IMHO the proposal is the right move because it 
 goes into the direction of unifying things in the language. the problem is 
 that it is difficult to see it without looking at the language as a whole. 
 then we realize that this can be connected to the change of dynamicType to 
 a function or to the fact that .Type and .Self might also warrant a 
 revisiting.
>>> 
>>> from a practical point of view, a @noreturn function is just so much 
>>> different than any other function. this shouldn't be "unified". we can 
>>> discuss if bottom types and normal types can be unified from a 
>>> theoretical/academical point of view. but in the real world, a @noreturn 
>>> function does not return at all, whereas most other function does return 
>>> execution to its caller. To honor this view, a function that returns `Void` 
>>> is meant to return, it just doesn't return any particular value. But `Void` 
>>> should be the type with no values, not the type with exactly one value, so 
>>> a function that returns `Void` shouldn't be able to return, because there 
>>> can be no `Void` value. `Void` is an unconstructable type, and yet it is 
>>> different from `@noreturn`. That would be a unification ;) 

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

[L Mihalkovic via swift-evolution]

> 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 will someday have variance annotations for generic 
> parameters and associated types so that we may express sound subtyping rules 
> between generic types. A real bottom type will fit in there just nicely.
> 
> +1 for a real bottom type
> +1 for calling it Never

+1 on all accounts (it is not the first time I find myself in agreement with 
many of the choices you support, and more interestingly, with the rational you 
use to support them: usually a mix between references to other examples and 
pragmatism).

here is another twist on Never… see further down...


> 
> -Thorsten 
> 
> 
>> Am 07.06.2016 um 22:43 schrieb Michael Peternell via swift-evolution 
>> >:
>> 
>> 
>>> 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-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 return. “Never" is a poor choice for that. Never what? Never 
>>> return? Never use this function? Never say never again?
>> 
>> "Never return". That's why it's in the return type slot, right after the 
>> `->`. If you read it out loud, you'll read "returns Never", which is 
>> exactly correct.
>> 
>> NoReturn, on the other hand, does *not* read well in that slot: "returns 
>> NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it 
>> makes no sense whatsoever *as a type name*.
> 
> But it’s *not* a type. You’ll never have an instance of it. Since it’s 
> not a type name, it doesn’t make sense that it needs to look like one. 
> What it is doing is telling you something about the behavior of the 
> function itself, not its return value. Its return value, if there were 
> one, is irrelevant, since the function, by its very nature, will never 
> even get to the point where it would return it. Either it’s going to kill 
> the app via a fatalError or something, or we have something like 
> dispatch_main() which will keep executing until the program stops, and 
> one way or another, it won’t return.
> 
> For that reason, frankly, I don’t understand why we want to change this 
> from being an attribute, which seems to me the more natural and logical 
> choice to describe this behavior. If we *do* have to change it, though, 
> NoReturn conveys the most clearly to the reader what it does.
 
 +1 for @noreturn
 We don't have to change it.
 We have to keep it.
>>> 
>>> 
>>> this is so unfortunate… IMHO the proposal is the right move because it goes 
>>> into the direction of unifying things in the language. the problem is that 
>>> it is difficult to see it without looking at the language as a whole. then 
>>> we realize that this can be connected to the change of dynamicType to a 
>>> function or to the fact that .Type and .Self might also warrant a 
>>> revisiting.
>> 
>> from a practical point of view, a @noreturn function is just so much 
>> different than any other function. this shouldn't be "unified". we can 
>> discuss if bottom types and normal types can be unified from a 
>> theoretical/academical point of view. but in the real world, a @noreturn 
>> function does not return at all, whereas most other function does return 
>> execution to its caller. To honor this view, a function that returns `Void` 
>> is meant to return, it just doesn't return any particular value. But `Void` 
>> should be the type with no values, not the type with exactly one value, so a 
>> function that returns `Void` shouldn't be able to return, because there can 
>> be no `Void` value. `Void` is an unconstructable type, and yet it is 
>> different from `@noreturn`. That would be a unification ;) . The whole 
>> concept of return-values is so much different in imperative programming than 
>> it is in Haskell and with "denotational semantics". Therefore we have 1) 
>> functions that 

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

[L Mihalkovic via swift-evolution]

> 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 will someday have variance annotations for generic 
> parameters and associated types so that we may express sound subtyping rules 
> between generic types. A real bottom type will fit in there just nicely.
> 
> +1 for a real bottom type
> +1 for calling it Never

+1 on all accounts (it is not the first time I find myself in agreement with 
many of the choices you support, and more interestingly, with the rational you 
use to support them: usually a mix between references to other examples and 
pragmatism).

here is another twist on Never… see further down...


> 
> -Thorsten 
> 
> 
>> Am 07.06.2016 um 22:43 schrieb Michael Peternell via swift-evolution 
>> >:
>> 
>> 
>>> 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-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 return. “Never" is a poor choice for that. Never what? Never 
>>> return? Never use this function? Never say never again?
>> 
>> "Never return". That's why it's in the return type slot, right after the 
>> `->`. If you read it out loud, you'll read "returns Never", which is 
>> exactly correct.
>> 
>> NoReturn, on the other hand, does *not* read well in that slot: "returns 
>> NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it 
>> makes no sense whatsoever *as a type name*.
> 
> But it’s *not* a type. You’ll never have an instance of it. Since it’s 
> not a type name, it doesn’t make sense that it needs to look like one. 
> What it is doing is telling you something about the behavior of the 
> function itself, not its return value. Its return value, if there were 
> one, is irrelevant, since the function, by its very nature, will never 
> even get to the point where it would return it. Either it’s going to kill 
> the app via a fatalError or something, or we have something like 
> dispatch_main() which will keep executing until the program stops, and 
> one way or another, it won’t return.
> 
> For that reason, frankly, I don’t understand why we want to change this 
> from being an attribute, which seems to me the more natural and logical 
> choice to describe this behavior. If we *do* have to change it, though, 
> NoReturn conveys the most clearly to the reader what it does.
 
 +1 for @noreturn
 We don't have to change it.
 We have to keep it.
>>> 
>>> 
>>> this is so unfortunate… IMHO the proposal is the right move because it goes 
>>> into the direction of unifying things in the language. the problem is that 
>>> it is difficult to see it without looking at the language as a whole. then 
>>> we realize that this can be connected to the change of dynamicType to a 
>>> function or to the fact that .Type and .Self might also warrant a 
>>> revisiting.
>> 
>> from a practical point of view, a @noreturn function is just so much 
>> different than any other function. this shouldn't be "unified". we can 
>> discuss if bottom types and normal types can be unified from a 
>> theoretical/academical point of view. but in the real world, a @noreturn 
>> function does not return at all, whereas most other function does return 
>> execution to its caller. To honor this view, a function that returns `Void` 
>> is meant to return, it just doesn't return any particular value. But `Void` 
>> should be the type with no values, not the type with exactly one value, so a 
>> function that returns `Void` shouldn't be able to return, because there can 
>> be no `Void` value. `Void` is an unconstructable type, and yet it is 
>> different from `@noreturn`. That would be a unification ;) . The whole 
>> concept of return-values is so much different in imperative programming than 
>> it is in Haskell and with "denotational semantics". Therefore we have 1) 
>> functions that return a value, e.g. `Int`, 2) functions that return no value 
>> (`Void`), and 3) functions that doesn't return at all (`@noreturn`) => I 
>> would like to keep it that way.

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

[Thorsten Seitz via swift-evolution]

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 method 
>> that is non-optional, but you never expect to be called. The only way to 
>> indicate that to the compiler is with an attribute.
> 
> If Swift permits return type covariance—that is, for an override or 
> implementation to tighten the return type—then this will happen naturally: 
> Never is a subtype of all types, so you can validly change any return type to 
> Never and meet the supertype's requirements.

Good point!

> 
> I believe Swift supports return type covariance for overridden methods, but 
> not for protocol requirements. This is, in my opinion, an incorrect behavior 
> which should be changed.

+1

-Thorsten 


> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Thorsten Seitz via swift-evolution]

> 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, the 
bottom type.

> When a function has a return type of R, it means that it does return a value 
> of type R.

From this follows naturally that a function with return type Never cannot 
return, because there is no such value in Never's empty set.

> 
> On the other hand, a @noreturn function doesn't return any value, so it 
> doesn't really have a return type. The whole concept of a "bottom type" was 
> made to create a model where every function can be specified as having a 
> return type. This isn't really a useful concept outside of the Haskell 
> language [1].

Actually Haskell does not have an explicit bottom type (which is not needed 
because there is no subtyping in Haskell) but other languages have like Scala 
and Ceylon. And Ceylon does very elegant things with its bottom type in 
conjunction with union types, e.g. discerning in the type system between 
Iterables statically known to be empty or non-empty. And Ceylon certainly is 
not an academic language as they have always strived (quite successful IMO) to 
be a language with easily understandable concepts. For example, they did 
introduce union and intersection types not for their theoretical power but to 
make all types representable as normal types of the language, even such types 
that have been inferred by the type system when dealing with generics, so that 
error messages from the compiler would be easily understandable. Only later 
they discovered how useful type unions and intersections are and how natural 
many things can be solved with them.

> 
> I like the "Basic Definition of a Type": while it does not generalize to 
> non-returning functions,

But it does if you include the empty set.

-Thorsten 


> it includes all functions in the mathematical sense; it includes all 
> functions that are meant to return a value. It includes all functions that 
> terminate and that neither crash nor throw. This "basic definition" is the 
> reason why we have functions at all. We don't have functions in order to 
> build an academic model where we can study denotational semantics [2] in, and 
> that is super-consistent. We have them to calculate things. And we don't 
> calculate values of type `NoReturn` or `Nothing`.


> 
> If I haven't convinced you yet => we'll meet again when casting votes for the 
> proposal (if it will ever go into formal review)
> 
> -Michael
> 
> [1] Yes, someone will find another language where it is useful too, but 
> anyhow, it's not useful for Swift, Java, Obj-C or C++.
> [2] https://en.wikibooks.org/wiki/Haskell/Denotational_semantics
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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 method that is 
> non-optional, but you never expect to be called. The only way to indicate 
> that to the compiler is with an attribute.

If Swift permits return type covariance—that is, for an override or 
implementation to tighten the return type—then this will happen naturally: 
Never is a subtype of all types, so you can validly change any return type to 
Never and meet the supertype's requirements.

I believe Swift supports return type covariance for overridden methods, but not 
for protocol requirements. This is, in my opinion, an incorrect behavior which 
should be changed.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Damien Sorresso via swift-evolution]

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 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 use 
 this function? Never say never again?
>>> 
>>> "Never return". That's why it's in the return type slot, right after the 
>>> `->`. If you read it out loud, you'll read "returns Never", which is 
>>> exactly correct.
>> 
>> 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 
>> indicate that to the compiler is with an attribute.
>> -damien
> 
> That would be lying to the type system like Java did in their collection 
> library throwing exceptions for some method implementations which is horribly 
> broken.
> If you conform to a protocol that means you sign a contract that all the 
> methods of the protocol may be called. There is no way out. 
> Except in cases with type parameters (or associated types in protocols) where 
> you might use Never for such a type parameter, thereby making all methods 
> taking arguments of this type uncallable without cheating the type system, 
> e.g.

In this scenario, the protocol has been defined in a sub-optimal way that is 
outside the bounds of your control. I'm totally sympathetic to the argument 
that it's wrong, but it does happen, so I am sympathetic to API clients who 
want to do as much of the right thing as possible while also registering their 
displeasure via an attribute.
-damien

> // quick and dirty example without method bodies and not to be taken too 
> seriously
> 
> protocol QueueType {
>associatedtype In
>associatedtype Out
>func enqueue(element: In)
>func dequeue() -> Out
> }
> 
> struct Queue : QueueType {
>func enqueue(element: In)
>func dequeue() -> Out
> }
> 
> struct Source : QueueType {
>func enqueue(element: Never)
>func dequeue() -> Out
> }
> 
> struct Sink : QueueType {
>func enqueue(element: In)
>func dequeue() -> Never
> }
> 
> let source: Source = ...
> let sink: Sink = ...
> let queue: Queue = ...
> queue.enqueue(source.dequeue())
> sink.enqueue(queue.dequeue())
> source.enqueue(1) // type error
> 
> -Thorsten 
> 
> 
> 
> 
> 
>> 
>>> NoReturn, on the other hand, does *not* read well in that slot: "returns 
>>> NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it makes 
>>> no sense whatsoever *as a type name*.
>>> 
 If you want bottom types for other uses, give them their own appropriate 
 and self documenting names.
>>> 
>>> 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 type named NoPass, but you can't—the type came from a NoReturn, and 
>>> it's stuck being a NoReturn.
>>> 
>>> Never works pretty well—honestly, surprisingly well—in all of these 
>>> contexts. The method returns Never, so optional chaining gives you an 
>>> Optional, so flatMap has a Never parameter. I have yet to discover a 
>>> case where it isn't easily interpreted to mean exactly what it really does 
>>> mean.
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution



smime.p7s
Description: S/MIME cryptographic signature
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

> 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 returning but who's 
never seen Swift before, and they will intuit what it does.

> And FWIW, "returns never" is hard to misinterpret, no?

“returns never” isn’t what you have, though. You have func foo() -> Never, 
which could mean a bunch of things. It could mean it never returns a *value*, 
i.e. a void return. It could mean someone made some crazy struct and named it 
Never. It’s not obvious from looking at it without prior knowledge of the 
system.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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".
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 it doesn't 
really have a return type. The whole concept of a "bottom type" was made to 
create a model where every function can be specified as having a return type. 
This isn't really a useful concept outside of the Haskell language [1].

I like the "Basic Definition of a Type": while it does not generalize to 
non-returning functions, it includes all functions in the mathematical sense; 
it includes all functions that are meant to return a value. It includes all 
functions that terminate and that neither crash nor throw. This "basic 
definition" is the reason why we have functions at all. We don't have functions 
in order to build an academic model where we can study denotational semantics 
[2] in, and that is super-consistent. We have them to calculate things. And we 
don't calculate values of type `NoReturn` or `Nothing`.

If I haven't convinced you yet => we'll meet again when casting votes for the 
proposal (if it will ever go into formal review)

-Michael

[1] Yes, someone will find another language where it is useful too, but anyhow, 
it's not useful for Swift, Java, Obj-C or C++.
[2] https://en.wikibooks.org/wiki/Haskell/Denotational_semantics

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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@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-evolution@swift.org> 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" is a poor choice for that. Never what? Never return? Never
> use this function? Never say never again?
> >> >>
> >> >> "Never return". That's why it's in the return type slot, right after
> the `->`. If you read it out loud, you'll read "returns Never", which is
> exactly correct.
> >> >>
> >> >> NoReturn, on the other hand, does *not* read well in that slot:
> "returns NoReturn". Huh? I mean, I suppose you won't misunderstand it, but
> it makes no sense whatsoever *as a type name*.
> >> >
> >> > But it’s *not* a type. You’ll never have an instance of it.
> >>
> >> That's the dictionary definition of a bottom type, though: a type which
> has no values.
> >>
> >> Since it’s not a type name, it doesn’t make sense that it needs to look
> like one. What it is doing is telling you something about the behavior of
> the function itself, not its return value. Its return value, if there were
> one, is irrelevant, since the function, by its very nature, will never even
> get to the point where it would return it.
> >>
> >> And that's the dictionary definition of a function where the return
> type is bottom. This isn't something being made up just for Swift...
> >
> > What’s the dictionary definition of a do loop? Or a for loop? Or
> try/catch?
> >
> > Swift doesn’t do things the same as other languages in lots of places. I
> don’t see why it has to be different here. @noreturn is a clearer
> description of what this construct does.
>
> Hi,
>
> I know of no other language that has a named bottom type that can
> syntactically compete with non-bottom-types. Swift would be the first (I
> think). The definition of bottom types hasn't been made up for Swift,
> right. "bottom type" is to "type" as is "javascript" to "java". Almost
> every language has a bottom type, including Swift 1. That doesn't mean that
> we should give it a name.


Scala has `Nothing`.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michael Peternell via swift-evolution]

> 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 made up on the 
> spot. No doubt, @noreturn is clearer today, but how much of that is because 
> it's what we already know? And FWIW, "returns never" is hard to misinterpret, 
> no?
> 

I disagree about the theoretical soundness here. It is implementable and 
doesn't introduce ambiguities, that's all IMHO.

-Michael

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michael Peternell via swift-evolution]

> 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 
>> > :
>> >
>> >> 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 does 
>> >>> not return. “Never" is a poor choice for that. Never what? Never return? 
>> >>> Never use this function? Never say never again?
>> >>
>> >> "Never return". That's why it's in the return type slot, right after the 
>> >> `->`. If you read it out loud, you'll read "returns Never", which is 
>> >> exactly correct.
>> >>
>> >> NoReturn, on the other hand, does *not* read well in that slot: "returns 
>> >> NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it 
>> >> makes no sense whatsoever *as a type name*.
>> >
>> > But it’s *not* a type. You’ll never have an instance of it.
>> 
>> That's the dictionary definition of a bottom type, though: a type which has 
>> no values.
>>  
>> Since it’s not a type name, it doesn’t make sense that it needs to look like 
>> one. What it is doing is telling you something about the behavior of the 
>> function itself, not its return value. Its return value, if there were one, 
>> is irrelevant, since the function, by its very nature, will never even get 
>> to the point where it would return it.
>> 
>> And that's the dictionary definition of a function where the return type is 
>> bottom. This isn't something being made up just for Swift...
> 
> What’s the dictionary definition of a do loop? Or a for loop? Or try/catch?
> 
> Swift doesn’t do things the same as other languages in lots of places. I 
> don’t see why it has to be different here. @noreturn is a clearer description 
> of what this construct does.

Hi,

I know of no other language that has a named bottom type that can syntactically 
compete with non-bottom-types. Swift would be the first (I think). The 
definition of bottom types hasn't been made up for Swift, right. "bottom type" 
is to "type" as is "javascript" to "java". Almost every language has a bottom 
type, including Swift 1. That doesn't mean that we should give it a name.

-Michael

> 
> Charles
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 <
>> swift-evolution@swift.org>:
>> >
>> >> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution <
>> swift-evolution@swift.org> 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" is a poor choice for that. Never what? Never return? Never
>> use this function? Never say never again?
>> >>
>> >> "Never return". That's why it's in the return type slot, right after
>> the `->`. If you read it out loud, you'll read "returns Never", which is
>> exactly correct.
>> >>
>> >> NoReturn, on the other hand, does *not* read well in that slot:
>> "returns NoReturn". Huh? I mean, I suppose you won't misunderstand it, but
>> it makes no sense whatsoever *as a type name*.
>> >
>> > But it’s *not* a type. You’ll never have an instance of it.
>
>
> That's the dictionary definition of a bottom type
> , though: a type which has no
> values.
>
>
>> Since it’s not a type name, it doesn’t make sense that it needs to look
>> like one. What it is doing is telling you something about the behavior of
>> the function itself, not its return value. Its return value, if there were
>> one, is irrelevant, since the function, by its very nature, will never even
>> get to the point where it would return it.
>
>
> And that's the dictionary definition of a function where the return type
> is bottom. This isn't something being made up just for Swift...
>
>
> What’s the dictionary definition of a do loop? Or a for loop? Or try/catch?
>
> Swift doesn’t do things the same as other languages in lots of places. I
> don’t see why it has to be different here. @noreturn is a clearer
> description of what this construct does.
>

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
made up on the spot. No doubt, @noreturn is clearer today, but how much of
that is because it's what we already know? And FWIW, "returns never" is
hard to misinterpret, no?


> Charles
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Thorsten Seitz via swift-evolution]

> 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 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 use this 
>>> function? Never say never again?
>> 
>> "Never return". That's why it's in the return type slot, right after the 
>> `->`. If you read it out loud, you'll read "returns Never", which is exactly 
>> correct.
> 
> 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 indicate 
> that to the compiler is with an attribute.
> -damien

That would be lying to the type system like Java did in their collection 
library throwing exceptions for some method implementations which is horribly 
broken.
If you conform to a protocol that means you sign a contract that all the 
methods of the protocol may be called. There is no way out. 
Except in cases with type parameters (or associated types in protocols) where 
you might use Never for such a type parameter, thereby making all methods 
taking arguments of this type uncallable without cheating the type system, e.g.

// quick and dirty example without method bodies and not to be taken too 
seriously

protocol QueueType {
associatedtype In
associatedtype Out
func enqueue(element: In)
func dequeue() -> Out
}

struct Queue : QueueType {
func enqueue(element: In)
func dequeue() -> Out
}

struct Source : QueueType {
func enqueue(element: Never)
func dequeue() -> Out
}

struct Sink : QueueType {
func enqueue(element: In)
func dequeue() -> Never
}

let source: Source = ...
let sink: Sink = ...
let queue: Queue = ...
queue.enqueue(source.dequeue())
sink.enqueue(queue.dequeue())
source.enqueue(1) // type error

-Thorsten 





> 
>> NoReturn, on the other hand, does *not* read well in that slot: "returns 
>> NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it makes 
>> no sense whatsoever *as a type name*.
>> 
>>> If you want bottom types for other uses, give them their own appropriate 
>>> and self documenting names.
>> 
>> 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 
>> type named NoPass, but you can't—the type came from a NoReturn, and it's 
>> stuck being a NoReturn.
>> 
>> Never works pretty well—honestly, surprisingly well—in all of these 
>> contexts. The method returns Never, so optional chaining gives you an 
>> Optional, so flatMap has a Never parameter. I have yet to discover a 
>> case where it isn't easily interpreted to mean exactly what it really does 
>> mean.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michael Peternell via swift-evolution]

> 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-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 return. 
> “Never" is a poor choice for that. Never what? Never return? Never use 
> this function? Never say never again? 
 
 "Never return". That's why it's in the return type slot, right after the 
 `->`. If you read it out loud, you'll read "returns Never", which is 
 exactly correct.
 
 NoReturn, on the other hand, does *not* read well in that slot: "returns 
 NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it makes 
 no sense whatsoever *as a type name*.
>>> 
>>> But it’s *not* a type. You’ll never have an instance of it. Since it’s not 
>>> a type name, it doesn’t make sense that it needs to look like one. What it 
>>> is doing is telling you something about the behavior of the function 
>>> itself, not its return value. Its return value, if there were one, is 
>>> irrelevant, since the function, by its very nature, will never even get to 
>>> the point where it would return it. Either it’s going to kill the app via a 
>>> fatalError or something, or we have something like dispatch_main() which 
>>> will keep executing until the program stops, and one way or another, it 
>>> won’t return.
>>> 
>>> For that reason, frankly, I don’t understand why we want to change this 
>>> from being an attribute, which seems to me the more natural and logical 
>>> choice to describe this behavior. If we *do* have to change it, though, 
>>> NoReturn conveys the most clearly to the reader what it does.
>> 
>> +1 for @noreturn
>> We don't have to change it.
>> We have to keep it.
> 
> 
> this is so unfortunate… IMHO the proposal is the right move because it goes 
> into the direction of unifying things in the language. the problem is that it 
> is difficult to see it without looking at the language as a whole. then we 
> realize that this can be connected to the change of dynamicType to a function 
> or to the fact that .Type and .Self might also warrant a revisiting. 

from a practical point of view, a @noreturn function is just so much different 
than any other function. this shouldn't be "unified". we can discuss if bottom 
types and normal types can be unified from a theoretical/academical point of 
view. but in the real world, a @noreturn function does not return at all, 
whereas most other function does return execution to its caller. To honor this 
view, a function that returns `Void` is meant to return, it just doesn't return 
any particular value. But `Void` should be the type with no values, not the 
type with exactly one value, so a function that returns `Void` shouldn't be 
able to return, because there can be no `Void` value. `Void` is an 
unconstructable type, and yet it is different from `@noreturn`. That would be a 
unification ;) . The whole concept of return-values is so much different in 
imperative programming than it is in Haskell and with "denotational semantics". 
Therefore we have 1) functions that return a value, e.g. `Int`, 2) functions 
that return no value (`Void`), and 3) functions that doesn't return at all 
(`@noreturn`) => I would like to keep it that way.

> 
> I do hope the core team does pull ranks and goes with it. Frankly I have no 
> stake in the name, and I would even argue that there might be a possible case 
> for doing something even more un-explainable than this change:
> 
> 1)  create aprotocol SwiftBottomType { }   [  the core team might defend 
> the idea that it should really be BuiltinBottomType, which I have no issues 
> with  ]
> 
> 2) then create  a  enum NoReturn: SwiftBottomType {}  
> 
> When looking at this question and a couple of other related ones, a pattern 
> should form, and the rational become self evident.
> 
> 
> 
>> 
>> -Michael
>> 
>>> 
>>> Charles
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___

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

[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 
> > >:
> >
> >> 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 does not return. 
> >>> “Never" is a poor choice for that. Never what? Never return? Never use 
> >>> this function? Never say never again?
> >>
> >> "Never return". That's why it's in the return type slot, right after the 
> >> `->`. If you read it out loud, you'll read "returns Never", which is 
> >> exactly correct.
> >>
> >> NoReturn, on the other hand, does *not* read well in that slot: "returns 
> >> NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it makes 
> >> no sense whatsoever *as a type name*.
> >
> > But it’s *not* a type. You’ll never have an instance of it.
> 
> That's the dictionary definition of a bottom type 
> , though: a type which has no 
> values.
>  
> Since it’s not a type name, it doesn’t make sense that it needs to look like 
> one. What it is doing is telling you something about the behavior of the 
> function itself, not its return value. Its return value, if there were one, 
> is irrelevant, since the function, by its very nature, will never even get to 
> the point where it would return it.
> 
> And that's the dictionary definition of a function where the return type is 
> bottom. This isn't something being made up just for Swift...

What’s the dictionary definition of a do loop? Or a for loop? Or try/catch?

Swift doesn’t do things the same as other languages in lots of places. I don’t 
see why it has to be different here. @noreturn is a clearer description of what 
this construct does.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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-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 return. 
 “Never" is a poor choice for that. Never what? Never return? Never use 
 this function? Never say never again? 
>>> 
>>> "Never return". That's why it's in the return type slot, right after the 
>>> `->`. If you read it out loud, you'll read "returns Never", which is 
>>> exactly correct.
>>> 
>>> NoReturn, on the other hand, does *not* read well in that slot: "returns 
>>> NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it makes 
>>> no sense whatsoever *as a type name*.
>> 
>> But it’s *not* a type. You’ll never have an instance of it. Since it’s not a 
>> type name, it doesn’t make sense that it needs to look like one. What it is 
>> doing is telling you something about the behavior of the function itself, 
>> not its return value. Its return value, if there were one, is irrelevant, 
>> since the function, by its very nature, will never even get to the point 
>> where it would return it. Either it’s going to kill the app via a fatalError 
>> or something, or we have something like dispatch_main() which will keep 
>> executing until the program stops, and one way or another, it won’t return.
>> 
>> For that reason, frankly, I don’t understand why we want to change this from 
>> being an attribute, which seems to me the more natural and logical choice to 
>> describe this behavior. If we *do* have to change it, though, NoReturn 
>> conveys the most clearly to the reader what it does.
> 
> +1 for @noreturn
> We don't have to change it.
> We have to keep it.


this is so unfortunate… IMHO the proposal is the right move because it goes 
into the direction of unifying things in the language. the problem is that it 
is difficult to see it without looking at the language as a whole. then we 
realize that this can be connected to the change of dynamicType to a function 
or to the fact that .Type and .Self might also warrant a revisiting. 

I do hope the core team does pull ranks and goes with it. Frankly I have no 
stake in the name, and I would even argue that there might be a possible case 
for doing something even more un-explainable than this change:

1)  create aprotocol SwiftBottomType { }   [  the core team might defend 
the idea that it should really be BuiltinBottomType, which I have no issues 
with  ]

2) then create  a  enum NoReturn: SwiftBottomType {}  

When looking at this question and a couple of other related ones, a pattern 
should form, and the rational become self evident.



> 
> -Michael
> 
>> 
>> Charles
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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-evolution@swift.org> 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" is a poor choice for that. Never what? Never return? Never
> use this function? Never say never again?
> >>
> >> "Never return". That's why it's in the return type slot, right after
> the `->`. If you read it out loud, you'll read "returns Never", which is
> exactly correct.
> >>
> >> NoReturn, on the other hand, does *not* read well in that slot:
> "returns NoReturn". Huh? I mean, I suppose you won't misunderstand it, but
> it makes no sense whatsoever *as a type name*.
> >
> > But it’s *not* a type. You’ll never have an instance of it.


That's the dictionary definition of a bottom type
, though: a type which has no
values.


> Since it’s not a type name, it doesn’t make sense that it needs to look
> like one. What it is doing is telling you something about the behavior of
> the function itself, not its return value. Its return value, if there were
> one, is irrelevant, since the function, by its very nature, will never even
> get to the point where it would return it.


And that's the dictionary definition of a function where the return type is
bottom. This isn't something being made up just for Swift...


> Either it’s going to kill the app via a fatalError or something, or we
> have something like dispatch_main() which will keep executing until the
> program stops, and one way or another, it won’t return.
> >
> > For that reason, frankly, I don’t understand why we want to change this
> from being an attribute, which seems to me the more natural and logical
> choice to describe this behavior. If we *do* have to change it, though,
> NoReturn conveys the most clearly to the reader what it does.
>
> +1 for @noreturn
> We don't have to change it.
> We have to keep it.
>
> -Michael
>
> >
> > Charles
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kevin Nattinger via swift-evolution]

> 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 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 use 
 this function? Never say never again? 
>>> 
>>> "Never return". That's why it's in the return type slot, right after the 
>>> `->`. If you read it out loud, you'll read "returns Never", which is 
>>> exactly correct.
>>> 
>>> NoReturn, on the other hand, does *not* read well in that slot: "returns 
>>> NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it makes 
>>> no sense whatsoever *as a type name*.
>> 
>> But it’s *not* a type. You’ll never have an instance of it. Since it’s not a 
>> type name, it doesn’t make sense that it needs to look like one. What it is 
>> doing is telling you something about the behavior of the function itself, 
>> not its return value. Its return value, if there were one, is irrelevant, 
>> since the function, by its very nature, will never even get to the point 
>> where it would return it. Either it’s going to kill the app via a fatalError 
>> or something, or we have something like dispatch_main() which will keep 
>> executing until the program stops, and one way or another, it won’t return.
>> 
>> For that reason, frankly, I don’t understand why we want to change this from 
>> being an attribute, which seems to me the more natural and logical choice to 
>> describe this behavior. If we *do* have to change it, though, NoReturn 
>> conveys the most clearly to the reader what it does.
> 
> +1 for @noreturn
> We don't have to change it.
> We have to keep it.

+1 from me too. 
Logically, “does not return" is an annotation: the function doesn’t return 
something that can’t be returned, it just doesn’t resume execution at the call 
point. 

> 
> -Michael
> 
>> 
>> Charles
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michael Peternell via swift-evolution]

> 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 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 use this 
>>> function? Never say never again? 
>> 
>> "Never return". That's why it's in the return type slot, right after the 
>> `->`. If you read it out loud, you'll read "returns Never", which is exactly 
>> correct.
>> 
>> NoReturn, on the other hand, does *not* read well in that slot: "returns 
>> NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it makes 
>> no sense whatsoever *as a type name*.
> 
> But it’s *not* a type. You’ll never have an instance of it. Since it’s not a 
> type name, it doesn’t make sense that it needs to look like one. What it is 
> doing is telling you something about the behavior of the function itself, not 
> its return value. Its return value, if there were one, is irrelevant, since 
> the function, by its very nature, will never even get to the point where it 
> would return it. Either it’s going to kill the app via a fatalError or 
> something, or we have something like dispatch_main() which will keep 
> executing until the program stops, and one way or another, it won’t return.
> 
> For that reason, frankly, I don’t understand why we want to change this from 
> being an attribute, which seems to me the more natural and logical choice to 
> describe this behavior. If we *do* have to change it, though, NoReturn 
> conveys the most clearly to the reader what it does.

+1 for @noreturn
We don't have to change it.
We have to keep it.

-Michael

> 
> Charles
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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 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 use this 
>> function? Never say never again? 
> 
> "Never return". That's why it's in the return type slot, right after the 
> `->`. If you read it out loud, you'll read "returns Never", which is exactly 
> correct.

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 indicate that 
to the compiler is with an attribute.
-damien

> NoReturn, on the other hand, does *not* read well in that slot: "returns 
> NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it makes no 
> sense whatsoever *as a type name*.
> 
>> If you want bottom types for other uses, give them their own appropriate and 
>> self documenting names. 
> 
> 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 
> type named NoPass, but you can't—the type came from a NoReturn, and it's 
> stuck being a NoReturn.
> 
> Never works pretty well—honestly, surprisingly well—in all of these contexts. 
> The method returns Never, so optional chaining gives you an Optional, 
> so flatMap has a Never parameter. I have yet to discover a case where it 
> isn't easily interpreted to mean exactly what it really does mean.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



smime.p7s
Description: S/MIME cryptographic signature
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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 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 use this 
>> function? Never say never again? 
> 
> "Never return". That's why it's in the return type slot, right after the 
> `->`. If you read it out loud, you'll read "returns Never", which is exactly 
> correct.
> 
> NoReturn, on the other hand, does *not* read well in that slot: "returns 
> NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it makes no 
> sense whatsoever *as a type name*.

But it’s *not* a type. You’ll never have an instance of it. Since it’s not a 
type name, it doesn’t make sense that it needs to look like one. What it is 
doing is telling you something about the behavior of the function itself, not 
its return value. Its return value, if there were one, is irrelevant, since the 
function, by its very nature, will never even get to the point where it would 
return it. Either it’s going to kill the app via a fatalError or something, or 
we have something like dispatch_main() which will keep executing until the 
program stops, and one way or another, it won’t return.

For that reason, frankly, I don’t understand why we want to change this from 
being an attribute, which seems to me the more natural and logical choice to 
describe this behavior. If we *do* have to change it, though, NoReturn conveys 
the most clearly to the reader what it does.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> 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 use this function? 
> Never say never again? 

"Never return". That's why it's in the return type slot, right after the `->`. 
If you read it out loud, you'll read "returns Never", which is exactly correct.

NoReturn, on the other hand, does *not* read well in that slot: "returns 
NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it makes no 
sense whatsoever *as a type name*.

> If you want bottom types for other uses, give them their own appropriate and 
> self documenting names. 

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 type 
named NoPass, but you can't—the type came from a NoReturn, and it's stuck being 
a NoReturn.

Never works pretty well—honestly, surprisingly well—in all of these contexts. 
The method returns Never, so optional chaining gives you an Optional, so 
flatMap has a Never parameter. I have yet to discover a case where it isn't 
easily interpreted to mean exactly what it really does mean.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Reed Mangino via swift-evolution]

+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 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jeremy Pereira via swift-evolution]

> 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
> > ,
> > this was what the core team had to say about it:
> >
> > /1) For noreturn, the core team prefers to explore a solution where a
> > function can be declared as returning an non-constructable “bottom”
> > type (e.g. an enum with zero cases).  This would lead to something 
> > like:/
> > /
> > /
> > /func abort() -> NoReturn { … }/
> 
> I.e. we need some type that will reflect "NoReturn" at first. Then, probably, 
> it can be used as bottom type. IMO `Never` is the best candidate at this 
> moment. For me it also can mean "never can have an instance of this type" or 
> "never be created" or "never be user”


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 use this function? Never 
say never again? 

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
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> 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 say so in the declaration. 
> The proposal just made the language less expressive!

Can you not see how strange this code is? You're saying the function cannot 
return, and then providing a return type. What does that even mean?

And Pyry is also correct: `func error(msg: String = "") -> Never` gives you the 
"assign to anything" semantics you're looking for anyway. What it does *not* 
allow you to do is something like:

@noreturn func error(msg: String = "") -> ErrorProtocol

But again, what is that supposed to mean? If you're planning to fill in the 
implementation later and are just temporarily `fatalError()ing`, why are you 
marking it `@noreturn`, undermining its use as a stub? And if you intend it to 
stay `@noreturn`, why are you specifying a return type it will never actually 
return?

If you're *not* returning an unconstrained generic type—a use case `Never`'s 
subtype-of-all-types nature intrinsically covers—what *is* the use case where 
you need to specify both a return type *and* that the function never returns 
*in* the function's signature?

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Антон Жилин via swift-evolution]

>
> @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 language less expressive!


Do we need to? One of use cases of this feature is to prototype using
unimplemented functions, i.e. lying about return type. In other cases,
return type of this function should be NoReturn/Never, as well.

You can write a foo-function that is really unintuitive:
> func foo() -> NoReturn {
>let x = fatalError("crash please")
>print("1+1=2")
>return x
> }


This is called "unreachable code", and this should give the same warning as
is currently given in such cases. Also you can currently create
sufficiently complex unreachable code that does not trigger a warning, and
nothing will change in that aspect.

Thinking about bottom-like behaviour, it would be a strict extension of
functionality of Never, so it can be discussed later in a separate proposal.

- Anton

2016-06-06 22:40 GMT+03:00 Michael Peternell :

>
> > Am 06.06.2016 um 00:53 schrieb Charles Srstka  >:
> >
> >> On Jun 5, 2016, at 5:41 PM, Michael Peternell via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >>> Am 05.06.2016 um 20:26 schrieb Антон Жилин via swift-evolution <
> swift-evolution@swift.org>:
> >>>
> >>> 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 zero
> possible values. The current `Void` would have to be renamed to `Unit`, the
> data type with exactly one possible value. Less C, More Haskell :) But
> wait, that's not really Haskell-ish, and it's not C-ish either.
> >
> > That is the most confusing possible thing that this could possibly be
> called. Seeing a Void return will cause anyone coming from a C, C++, ObjC,
> etc. background to think of something that is definitely *not* a no-return
> function.
>
> I agree. For this reason, my email continued after that paragraph. I
> deliberately ended the last sentence of that paragraph with "But wait,
> that's not really..."
>
> There is a really really good reason why Haskell doesn't have a named
> "bottom type" like "None" or "Void". The bottom type has type `forall a.
> a`, corresponding to the mathematical fact that from "false" follows
> anything. Assigning a bottom type to a variable makes only sense in
> Haskell, because it uses lazy evaluation. With strict evaluation, a bottom
> type is just confusing at best. And a `Nothing` type corresponds to
> Haskell's `Void` type, not to its bottom type - a really exotic type that
> is seldom used. Its not consistent to have a @noreturn-function return
> `Nothing` instead, because `Nothing` that's not a proper type. You can
> write a foo-function that is really unintuitive:
>
> func foo() -> NoReturn {
>let x = fatalError("crash please")
>print("1+1=2")
>return x
> }
>
> Shouldn't we all just try to understand the rationale for the current
> language behavior before we try to propose changes?
>
> 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 say so in the declaration.
> The proposal just made the language less expressive!
>
> See also:
> https://en.wikibooks.org/wiki/Haskell/Denotational_semantics
> for a more in-depth explanation why "bottom" is not an ordinary type with
> a name.
>
> -Michael
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Pyry Jahkola via swift-evolution]

> 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 {
>fatalError("bottom: \(msg)")
> }
> 
> It still returns bottom, but there is no way to say so in the declaration. 
> The proposal just made the language less expressive!

This isn't my understanding of the idea. My understanding is that instead of a 
generic function, you'd write `error` as:

func error(_ msg: String = "") -> Never {
fatalError("bottom: \(msg)")
// or equivalently, since fatalError() also returns Never:
//return fatalError("bottom: \(msg)")
}

And because `Never` is a real bottom type (this is probably the extra compiler 
support needed that Chris Lattner referred to), you can use this function in 
any type context, meaning that it behaves as if it's of type `∀x. String → x`:

// Example 1:
func someImplementationDetail(input: Int) -> [String] {
// ...
return error("unimplemented for now")
}

// Example 2:
var ints: [Int] = []
ints.append(error("FIXME"))

// Example 3:
let e: Either = ...
let s: String = e.left ?? e.right ?? error("impossible")

I would even consider specifying that every empty enum type behaves like this, 
and that `Never` was just the default you should probably use, defined in the 
stdlib as:

/// The bottom type, or return type of functions that do not return.
/// This enum is intentionally empty.
enum Never {}

In other words in my imagination, there would be no magic in the type `Never` 
per se, but in the treatment of empty enums in general.

— Pyry

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michael Peternell via swift-evolution]

> 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 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 zero possible 
>> values. The current `Void` would have to be renamed to `Unit`, the data type 
>> with exactly one possible value. Less C, More Haskell :) But wait, that's 
>> not really Haskell-ish, and it's not C-ish either.
> 
> That is the most confusing possible thing that this could possibly be called. 
> Seeing a Void return will cause anyone coming from a C, C++, ObjC, etc. 
> background to think of something that is definitely *not* a no-return 
> function.

I agree. For this reason, my email continued after that paragraph. I 
deliberately ended the last sentence of that paragraph with "But wait, that's 
not really..."

There is a really really good reason why Haskell doesn't have a named "bottom 
type" like "None" or "Void". The bottom type has type `forall a. a`, 
corresponding to the mathematical fact that from "false" follows anything. 
Assigning a bottom type to a variable makes only sense in Haskell, because it 
uses lazy evaluation. With strict evaluation, a bottom type is just confusing 
at best. And a `Nothing` type corresponds to Haskell's `Void` type, not to its 
bottom type - a really exotic type that is seldom used. Its not consistent to 
have a @noreturn-function return `Nothing` instead, because `Nothing` that's 
not a proper type. You can write a foo-function that is really unintuitive:

func foo() -> NoReturn {
   let x = fatalError("crash please")
   print("1+1=2")
   return x
}

Shouldn't we all just try to understand the rationale for the current language 
behavior before we try to propose changes?

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 say so in the declaration. The 
proposal just made the language less expressive!

See also:
https://en.wikibooks.org/wiki/Haskell/Denotational_semantics
for a more in-depth explanation why "bottom" is not an ordinary type with a 
name.

-Michael

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Thorsten Seitz via swift-evolution]

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 possibly empty iterable where last: Element | Null, i.e. 
last: Element?
Iterable // a non-empty iterable where last: Element | Never, 
i.e. last: Element

This achieves type safety for `last` (and a couple of other methods not shown 
here) with respect to the property of an iterable statically known to be 
non-empty.
This is very elegant IMHO.

-Thorsten


> Am 06.06.2016 um 19:46 schrieb Jacob Bandes-Storch via swift-evolution 
> :
> 
> 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 
> > wrote:
> `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 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 
> > 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 enum, with no compiler magic except that functions 
> > returning None are equivalent to current @noreturn.
> >
> > Example 1.
> > let x: None?
> > // ...
> > let y = x!
> >
> > It will trap in runtime not because we discover scary bottom thing, as in 
> > Haskell, but because x had value Optional.none at that moment and we 
> > asserted otherwise.
> > We could prove that it is always true in this case, but compiler must be 
> > stupid about this.
> >
> > Example 2.
> > Compiler should allow including None in structures. Error will show up in 
> > constructor, when we will not be able to initialize the field.
> >
> > Example 3.
> > None in an enum case makes that case never appear in values of such a type. 
> > But compiler can not know about that.
> >
> > - Anton
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org 
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > 
> >
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org 
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jacob Bandes-Storch via swift-evolution]

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
> alternative.
>
> -Joe
>
> > On Jun 5, 2016, at 11:37 AM, T.J. Usiyan via swift-evolution <
> swift-evolution@swift.org> 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 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 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 enum, with no compiler magic except that
> functions returning None are equivalent to current @noreturn.
> >
> > Example 1.
> > let x: None?
> > // ...
> > let y = x!
> >
> > It will trap in runtime not because we discover scary bottom thing, as
> in Haskell, but because x had value Optional.none at that moment and we
> asserted otherwise.
> > We could prove that it is always true in this case, but compiler must be
> stupid about this.
> >
> > Example 2.
> > Compiler should allow including None in structures. Error will show up
> in constructor, when we will not be able to initialize the field.
> >
> > Example 3.
> > None in an enum case makes that case never appear in values of such a
> type. But compiler can not know about that.
> >
> > - Anton
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joe Groff via swift-evolution]

`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 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 
> 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 enum, with no compiler magic except that functions 
> returning None are equivalent to current @noreturn.
> 
> Example 1.
> let x: None?
> // ...
> let y = x!
> 
> It will trap in runtime not because we discover scary bottom thing, as in 
> Haskell, but because x had value Optional.none at that moment and we asserted 
> otherwise.
> We could prove that it is always true in this case, but compiler must be 
> stupid about this.
> 
> Example 2.
> Compiler should allow including None in structures. Error will show up in 
> constructor, when we will not be able to initialize the field.
> 
> Example 3.
> None in an enum case makes that case never appear in values of such a type. 
> But compiler can not know about that.
> 
> - Anton
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

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 to 
standardize the lower levels of the stdlib around a few simple patterns that 
can directly impact the design of all these solutions (some are already in 
place, and should likely influence the shape of the answer to this question, 
regardless of the selected name).

I am gathering a handfull of these really small proposals which I believe make 
more sense when looked at together.

Regards
(From mobile)

> On Jun 6, 2016, at 5:26 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> "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 to me. On the other hand:
> 
> func foo() -> Never
> 
> I read that as "a function foo that returns never". That's perfectly clear to 
> me.
> 
> When it comes to naming things like this, I don't think we should try to 
> shoehorn in the arguably more "pure" names when it runs the risk of causing 
> confusion with Swift's C-based ancestry. 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 main audience here is still app developers and perhaps 
> backend developers, not academics.
> 
>> On Mon, Jun 6, 2016 at 8:16 AM Charlie Monroe via swift-evolution 
>>  wrote:
>> 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, Vladimir.S via swift-evolution 
>> :
>> 
>> > +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 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 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. Possibly, to avoid confusion with nil, calling it Null? Though 
>>  that might get confused with NSNull, once the NS prefix gets dropped.
>> 
>>  Or "Nothing" as in Scala.
>> 
>> > On Jun 5, 2016, at 8:26 PM, Антон Жилин 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 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.
>> >
>> > Example 1.
>> > let x: None?
>> > // ...
>> > let y = x!
>> >
>> > It will trap in runtime not because we discover scary bottom thing, as 
>> > in Haskell, but because x had value Optional.none at that moment and 
>> > we asserted otherwise.
>> > We could prove that it is always true in this case, but compiler must 
>> > be stupid about this.
>> >
>> > Example 2.
>> > Compiler should allow including None in structures. Error will show up 
>> > in constructor, when we will not be able to initialize the field.
>> >
>> > Example 3.
>> > None in an enum case makes that case never appear in values of such a 
>> > type. But compiler can not know about that.
>> >
>> > - Anton
>> > ___
>> > 

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

[Xiaodi Wu via swift-evolution]

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 understand.
>
>
> The semantics might help a person better understand the philosophy of the
> language. The @noreturn methods are *not* being written very often, and
> definitely not by newcomers, who are usually fine knowing there's
> fatalError and that's it. For a person who has a deeper insight into the
> language, semantic consistency may be good thing.
>

No, but it will be *read* by many, and those who are reading but not
writing these methods are particularly in need of clarity as to what it
does. A distinction between a method that returns None vs. a method that
returns Void is going to be ridiculously nonsensical for such a user.

In any case, if we need a 'consistent' word, `Never` can be paired with
`Every`.


> The main audience here is still app developers and perhaps backend
> developers, not academics.
>
> On Mon, Jun 6, 2016 at 8:16 AM Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> 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, Vladimir.S via swift-evolution <
>> swift-evolution@swift.org>:
>>
>> > +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 the current suggestions would be Never.
>> >>
>> >> -Thorsten
>> >>
>> >>> Am 06.06.2016 um 15:24 schrieb Thorsten Seitz via swift-evolution <
>> swift-evolution@swift.org>:
>> >>>
>> >>> Ceylon uses `Nothing` for the bottom type.
>> >>>
>> >>> -Thorsten
>> >>>
>>  Am 05.06.2016 um 20:39 schrieb Charlie Monroe via swift-evolution <
>> swift-evolution@swift.org>:
>> 
>>  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. Possibly, to avoid confusion with nil, calling it Null? Though that
>> might get confused with NSNull, once the NS prefix gets dropped.
>> 
>>  Or "Nothing" as in Scala.
>> 
>> > On Jun 5, 2016, at 8:26 PM, Антон Жилин via swift-evolution <
>> swift-evolution@swift.org> 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 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.
>> >
>> > Example 1.
>> > let x: None?
>> > // ...
>> > let y = x!
>> >
>> > It will trap in runtime not because we discover scary bottom thing,
>> as in Haskell, but because x had value Optional.none at that moment and we
>> asserted otherwise.
>> > We could prove that it is always true in this case, but compiler
>> must be stupid about this.
>> >
>> > Example 2.
>> > Compiler should allow including None in structures. Error will show
>> up in constructor, when we will not be able to initialize the field.
>> >
>> > Example 3.
>> > None in an enum case makes that case never appear in values of such
>> a type. But compiler can not know about that.
>> >
>> > - Anton
>> > ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>>  ___
>>  swift-evolution mailing list
>>  swift-evolution@swift.org
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> >>> ___
>> >>> swift-evolution mailing list
>> >>> swift-evolution@swift.org
>> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >> ___
>> >> swift-evolution mailing list
>> >> swift-evolution@swift.org
>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>> > ___
>> > swift-evolution 

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

[Charlie Monroe via swift-evolution]

> 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 @noreturn methods are *not* being written very often, and 
definitely not by newcomers, who are usually fine knowing there's fatalError 
and that's it. For a person who has a deeper insight into the language, 
semantic consistency may be good thing.

> The main audience here is still app developers and perhaps backend 
> developers, not academics.
> 
> On Mon, Jun 6, 2016 at 8:16 AM Charlie Monroe via swift-evolution 
> > wrote:
> 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, Vladimir.S via swift-evolution  >:
> 
> > +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 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 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. 
>  Possibly, to avoid confusion with nil, calling it Null? Though that 
>  might get confused with NSNull, once the NS prefix gets dropped.
> 
>  Or "Nothing" as in Scala.
> 
> > On Jun 5, 2016, at 8:26 PM, Антон Жилин 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 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.
> >
> > Example 1.
> > let x: None?
> > // ...
> > let y = x!
> >
> > It will trap in runtime not because we discover scary bottom thing, as 
> > in Haskell, but because x had value Optional.none at that moment and we 
> > asserted otherwise.
> > We could prove that it is always true in this case, but compiler must 
> > be stupid about this.
> >
> > Example 2.
> > Compiler should allow including None in structures. Error will show up 
> > in constructor, when we will not be able to initialize the field.
> >
> > Example 3.
> > None in an enum case makes that case never appear in values of such a 
> > type. But compiler can not know about that.
> >
> > - Anton
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org 
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > 
> 
>  ___
>  swift-evolution mailing list
>  swift-evolution@swift.org 
>  https://lists.swift.org/mailman/listinfo/swift-evolution 
>  
> >>> ___
> >>> swift-evolution mailing list
> >>> swift-evolution@swift.org 
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution 
> >>> 
> >> ___
> >> swift-evolution mailing list
> >> swift-evolution@swift.org 
> >> https://lists.swift.org/mailman/listinfo/swift-evolution 
> >> 

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

[Tony Allevato via swift-evolution]

"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 to me. On the other hand:

func foo() -> Never

I read that as "a function foo that returns never". That's perfectly clear
to me.

When it comes to naming things like this, I don't think we should try to
shoehorn in the arguably more "pure" names when it runs the risk of causing
confusion with Swift's C-based ancestry. 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 main audience here is still app developers and
perhaps backend developers, not academics.

On Mon, Jun 6, 2016 at 8:16 AM Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

> 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, Vladimir.S via swift-evolution <
> swift-evolution@swift.org>:
>
> > +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 the current suggestions would be Never.
> >>
> >> -Thorsten
> >>
> >>> Am 06.06.2016 um 15:24 schrieb Thorsten Seitz via swift-evolution <
> swift-evolution@swift.org>:
> >>>
> >>> Ceylon uses `Nothing` for the bottom type.
> >>>
> >>> -Thorsten
> >>>
>  Am 05.06.2016 um 20:39 schrieb Charlie Monroe via swift-evolution <
> swift-evolution@swift.org>:
> 
>  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. Possibly, to avoid confusion with nil, calling it Null? Though that
> might get confused with NSNull, once the NS prefix gets dropped.
> 
>  Or "Nothing" as in Scala.
> 
> > On Jun 5, 2016, at 8:26 PM, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> 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 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.
> >
> > Example 1.
> > let x: None?
> > // ...
> > let y = x!
> >
> > It will trap in runtime not because we discover scary bottom thing,
> as in Haskell, but because x had value Optional.none at that moment and we
> asserted otherwise.
> > We could prove that it is always true in this case, but compiler
> must be stupid about this.
> >
> > Example 2.
> > Compiler should allow including None in structures. Error will show
> up in constructor, when we will not be able to initialize the field.
> >
> > Example 3.
> > None in an enum case makes that case never appear in values of such
> a type. But compiler can not know about that.
> >
> > - Anton
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> 
>  ___
>  swift-evolution mailing list
>  swift-evolution@swift.org
>  https://lists.swift.org/mailman/listinfo/swift-evolution
> >>> ___
> >>> swift-evolution mailing list
> >>> swift-evolution@swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >> ___
> >> swift-evolution mailing list
> >> swift-evolution@swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

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

[Charlie Monroe via swift-evolution]

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, Vladimir.S via swift-evolution : 

> +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 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 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. 
 Possibly, to avoid confusion with nil, calling it Null? Though that might 
 get confused with NSNull, once the NS prefix gets dropped.
 
 Or "Nothing" as in Scala.
 
> On Jun 5, 2016, at 8:26 PM, Антон Жилин 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 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.
> 
> Example 1.
> let x: None?
> // ...
> let y = x!
> 
> It will trap in runtime not because we discover scary bottom thing, as in 
> Haskell, but because x had value Optional.none at that moment and we 
> asserted otherwise.
> We could prove that it is always true in this case, but compiler must be 
> stupid about this.
> 
> Example 2.
> Compiler should allow including None in structures. Error will show up in 
> constructor, when we will not be able to initialize the field.
> 
> Example 3.
> None in an enum case makes that case never appear in values of such a 
> type. But compiler can not know about that.
> 
> - Anton
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

+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 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 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. Possibly, to avoid confusion with nil, calling it Null? Though 
that might get confused with NSNull, once the NS prefix gets dropped.

Or "Nothing" as in Scala.


On Jun 5, 2016, at 8:26 PM, Антон Жилин 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 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.

Example 1.
let x: None?
// ...
let y = x!

It will trap in runtime not because we discover scary bottom thing, as in 
Haskell, but because x had value Optional.none at that moment and we asserted 
otherwise.
We could prove that it is always true in this case, but compiler must be stupid 
about this.

Example 2.
Compiler should allow including None in structures. Error will show up in 
constructor, when we will not be able to initialize the field.

Example 3.
None in an enum case makes that case never appear in values of such a type. But 
compiler can not know about that.

- Anton
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Thorsten Seitz via swift-evolution]

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 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. 
>> Possibly, to avoid confusion with nil, calling it Null? Though that might 
>> get confused with NSNull, once the NS prefix gets dropped.
>> 
>> Or "Nothing" as in Scala.
>> 
>>> On Jun 5, 2016, at 8:26 PM, Антон Жилин 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 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.
>>> 
>>> Example 1.
>>> let x: None?
>>> // ...
>>> let y = x!
>>> 
>>> It will trap in runtime not because we discover scary bottom thing, as in 
>>> Haskell, but because x had value Optional.none at that moment and we 
>>> asserted otherwise.
>>> We could prove that it is always true in this case, but compiler must be 
>>> stupid about this.
>>> 
>>> Example 2.
>>> Compiler should allow including None in structures. Error will show up in 
>>> constructor, when we will not be able to initialize the field.
>>> 
>>> Example 3.
>>> None in an enum case makes that case never appear in values of such a type. 
>>> But compiler can not know about that.
>>> 
>>> - Anton
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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 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. 
> Possibly, to avoid confusion with nil, calling it Null? Though that might get 
> confused with NSNull, once the NS prefix gets dropped.
> 
> Or "Nothing" as in Scala.
> 
>> On Jun 5, 2016, at 8:26 PM, Антон Жилин 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 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.
>> 
>> Example 1.
>> let x: None?
>> // ...
>> let y = x!
>> 
>> It will trap in runtime not because we discover scary bottom thing, as in 
>> Haskell, but because x had value Optional.none at that moment and we 
>> asserted otherwise.
>> We could prove that it is always true in this case, but compiler must be 
>> stupid about this.
>> 
>> Example 2.
>> Compiler should allow including None in structures. Error will show up in 
>> constructor, when we will not be able to initialize the field.
>> 
>> Example 3.
>> None in an enum case makes that case never appear in values of such a type. 
>> But compiler can not know about that.
>> 
>> - Anton
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

>> 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 to this protocol. You *should* be able to 
> cast anything to Nothing, which this definition doesn't allow. You should be 
> able to call any method, property, or subscript on Nothing* (none of them 
> will actually work), but Nothing has no methods. A `protocol Nothing` is, 
> frankly, the exact *opposite* of what Nothing should be.

Interesting viewpoint. My only issue with it is that it tends to perpetuate the 
magic that exists between compiler and stdlib: there are many areas where they 
seem to be gratuitiously joined at the hip by shared secret hanshakes. 

> 
> 
> * At least notionally. It wouldn't be wrong to omit that as clever, but 
> pointless.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Антон Жилин via swift-evolution]

> 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 it in a `switch`
statement?

Nice points! I tried to keep things as simple as possible, but it looks
like such special cases would really help here.

> I wonder if perhaps your experience with Haskell has given you a false
impression of how this would work in Swift. Haskell is a pervasively lazy
language. Every operation in Haskell is lazy and you have little control
over when anything executes. Because of this, `undefined` values can
persist for long periods of time and spread deep into your code. But Swift
is not pervasively lazy; it is (relatively) simple and obvious to figure
out when a given piece of code will run. When you run a
Bottom/None/Never-returning expression, it does not return. Period. There
is no "it does not return six files away from where you wrote it".

We need Never to be subtype of any type, including structs and final
classes, but it's difficult to wrap my head around this while we don't have
subtypes in Swift.
Anyway, I see little to no problems with this. Just the proposal is going
to become longer than I expected :)

- Anton

2016-06-06 11:12 GMT+03:00 Brent Royal-Gordon :

> > 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 a C
> background. (Actually, it's probably the most *natural* name for what we
> call Void.) `func x() -> None` reads like it returns nothing. `func x() ->
> Never` reads like it does not return.
>
> > 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.
>
> Could you elaborate on this? I think it would be really useful to have a
> bottom type—useful to the point that, within minutes of deciding to think
> of examples, I quickly came up with some really good ones. Why don't you
> like having a bottom type?
>
> > Example 1.
> > let x: None?
> > // ...
> > let y = x!
> >
> > It will trap in runtime not because we discover scary bottom thing, as
> in Haskell, but because x had value Optional.none at that moment and we
> asserted otherwise.
>
> I'm not sure what you mean by this. There is no "scary bottom thing";
> Bottom or None or Never or whatever you call it is still an empty type, and
> the unwrap still fails because the value is `.none`, not `.some`. The only
> difference is that you can say something like `let total = basicBooks +
> fatalError("implement pro books counting")` in an expression and it will
> compile, since Bottom/None/Never is a subtype of `basicBooks`'s type—it's
> simply one that will never actually be created.
>
> I wonder if perhaps your experience with Haskell has given you a false
> impression of how this would work in Swift. Haskell is a pervasively lazy
> language. Every operation in Haskell is lazy and you have little control
> over when anything executes. Because of this, `undefined` values can
> persist for long periods of time and spread deep into your code. But Swift
> is not pervasively lazy; it is (relatively) simple and obvious to figure
> out when a given piece of code will run. When you run a
> Bottom/None/Never-returning expression, it does not return. Period. There
> is no "it does not return six files away from where you wrote it".
>
> > We could prove that it is always true in this case, but compiler must be
> stupid about this.
>
> 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?
>
> > Example 2.
> > Compiler should allow including None in structures. Error will show up
> in constructor, when we will not be able to initialize the field.
>
> Well, you can assign the field from a call to something like
> `fatalError()`, but of course that will crash at runtime. (That's true
> whether we use a bottom type or an empty type, by the way.)
>
> > Example 3.
> > None in an enum case makes that case never appear in values of such a
> type. But compiler can not know about that.
>
> Again: Why? 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 it in a `switch`
> statement? What's the advantage of not being able to eliminate dead code,
> or call out code that will inevitably fail? We already want these things
> for other uses of Bottom/None/Never, like dead code 

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

[Brent Royal-Gordon via swift-evolution]

> 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, and a very natural way to design things *if* Never is a 
proper bottom type, instead of just an empty enum. I don't even think you can 
really describe this as "compiler magic": Just as a function with no return 
type implicitly returns Void, so a function with no throw type implicitly 
throws Never.

(Incidentally, the `E` should be `E: ErrorProtocol`, I believe, since you can 
only throw ErrorProtocols. That's why Never needs to be a proper bottom type: 
it needs to conform to `ErrorProtocol`.)

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> 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 to this protocol. You *should* be able to cast 
anything to Nothing, which this definition doesn't allow. You should be able to 
call any method, property, or subscript on Nothing* (none of them will actually 
work), but Nothing has no methods. A `protocol Nothing` is, frankly, the exact 
*opposite* of what Nothing should be.


* At least notionally. It wouldn't be wrong to omit that as clever, but 
pointless.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> 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 think Nil or Null are good answers here. Whatever their dictionary 
definitions, they have specific meanings to programmers.

(Actually, I could kind of see *lowercase* `nil`—the nil literal—being an okay 
option, if only because it would look bizarre. In that case, it would be 
indicating a lack-of-type. `Nil`, though, looks like it is the type of `nil`, 
and in many languages it is.)

> Or "Nothing" as in Scala.

I think `Nothing` suffers from a slightly less serious case of `None`: it looks 
like a sensible alternate word for `Void`. If you heard someone say a function 
"returns nothing", would you think that means it doesn't return, or that it 
returns but doesn't return any data?

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon 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 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 a C background. (Actually, 
it's probably the most *natural* name for what we call Void.) `func x() -> 
None` reads like it returns nothing. `func x() -> Never` reads like it does not 
return.

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

Could you elaborate on this? I think it would be really useful to have a bottom 
type—useful to the point that, within minutes of deciding to think of examples, 
I quickly came up with some really good ones. Why don't you like having a 
bottom type?

> Example 1.
> let x: None?
> // ...
> let y = x!
> 
> It will trap in runtime not because we discover scary bottom thing, as in 
> Haskell, but because x had value Optional.none at that moment and we asserted 
> otherwise.

I'm not sure what you mean by this. There is no "scary bottom thing"; Bottom or 
None or Never or whatever you call it is still an empty type, and the unwrap 
still fails because the value is `.none`, not `.some`. The only difference is 
that you can say something like `let total = basicBooks + fatalError("implement 
pro books counting")` in an expression and it will compile, since 
Bottom/None/Never is a subtype of `basicBooks`'s type—it's simply one that will 
never actually be created.

I wonder if perhaps your experience with Haskell has given you a false 
impression of how this would work in Swift. Haskell is a pervasively lazy 
language. Every operation in Haskell is lazy and you have little control over 
when anything executes. Because of this, `undefined` values can persist for 
long periods of time and spread deep into your code. But Swift is not 
pervasively lazy; it is (relatively) simple and obvious to figure out when a 
given piece of code will run. When you run a Bottom/None/Never-returning 
expression, it does not return. Period. There is no "it does not return six 
files away from where you wrote it".

> We could prove that it is always true in this case, but compiler must be 
> stupid about this.

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?

> Example 2.
> Compiler should allow including None in structures. Error will show up in 
> constructor, when we will not be able to initialize the field.

Well, you can assign the field from a call to something like `fatalError()`, 
but of course that will crash at runtime. (That's true whether we use a bottom 
type or an empty type, by the way.)

> Example 3.
> None in an enum case makes that case never appear in values of such a type. 
> But compiler can not know about that.

Again: Why? 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 it in a `switch` 
statement? What's the advantage of not being able to eliminate dead code, or 
call out code that will inevitably fail? We already want these things for other 
uses of Bottom/None/Never, like dead code elimination after a precondition 
fails. Why not here?

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[LM via swift-evolution]

> 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:
>> 
>> 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 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 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), 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.
 
 Or "Nothing" as in Scala.
 
 > On Jun 5, 2016, at 8:26 PM, Антон Жилин 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 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.
 >
 > Example 1.
 > let x: None?
 > // ...
 > let y = x!
 >
 > It will trap in runtime not because we discover scary bottom thing, as 
 > in Haskell, but because x had value Optional.none at that moment and we 
 > asserted otherwise.
 > We could prove that it is always true in this case, but compiler must be 
 > stupid about this.
 >
 > Example 2.
 > Compiler should allow including None in structures. Error will show up 
 > in constructor, when we will not be able to initialize the field.
 >
 > Example 3.
 > None in an enum case makes that case never appear in values of such a 
 > type. But compiler can not know about that.
 >
 > - Anton
 > ___
 > swift-evolution mailing list
 > swift-evolution@swift.org
 > https://lists.swift.org/mailman/listinfo/swift-evolution
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

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 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 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 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), 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.
>>> 
>>> Or "Nothing" as in Scala.
>>> 
>>> > On Jun 5, 2016, at 8:26 PM, Антон Жилин 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 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.
>>> >
>>> > Example 1.
>>> > let x: None?
>>> > // ...
>>> > let y = x!
>>> >
>>> > It will trap in runtime not because we discover scary bottom thing, as in 
>>> > Haskell, but because x had value Optional.none at that moment and we 
>>> > asserted otherwise.
>>> > We could prove that it is always true in this case, but compiler must be 
>>> > stupid about this.
>>> >
>>> > Example 2.
>>> > Compiler should allow including None in structures. Error will show up in 
>>> > constructor, when we will not be able to initialize the field.
>>> >
>>> > Example 3.
>>> > None in an enum case makes that case never appear in values of such a 
>>> > type. But compiler can not know about that.
>>> >
>>> > - Anton
>>> > ___
>>> > swift-evolution mailing list
>>> > swift-evolution@swift.org
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Антон Жилин via swift-evolution]

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

> On Jun 5, 2016, at 5:41 PM, Michael Peternell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> Am 05.06.2016 um 20:26 schrieb Антон Жилин via swift-evolution <
> swift-evolution@swift.org>:
>
> 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 zero possible
> values. The current `Void` would have to be renamed to `Unit`, the data
> type with exactly one possible value. Less C, More Haskell :) But wait,
> that's not really Haskell-ish, and it's not C-ish either.
>
>
> That is the most confusing possible thing that this could possibly be
> called. Seeing a Void return will cause anyone coming from a C, C++, ObjC,
> etc. background to think of something that is definitely *not* a no-return
> function.
>
> Charles
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michael Peternell via swift-evolution]

> 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 zero possible 
values. The current `Void` would have to be renamed to `Unit`, the data type 
with exactly one possible value. Less C, More Haskell :) But wait, that's not 
really Haskell-ish, and it's not C-ish either.

From a typing perspective, it's nice to have a noreturn-function be able to 
return any type. For example, the Haskell `error` function has type `String -> 
a`, so you can write

fib :: Integer -> Integer
fib x = error "fib not yet implemented. Sorry"

and it will crash at runtime. Does this make sense for Swift? I don't think so. 
Swift is not a functional programming language, so I think that @noreturn 
shouldn't be force-fitted to look like a type. Given that most developers don't 
really think functionally, but rather imperatively, I don't think it's nice to 
force them to think functionally if they want to understand why @noreturn has 
been turned into `None`.

> 
> I would prefer the type to be simple, and be implemented as a case-less enum 
> (not a bottom value, as in Haskell).

That's a problem. Because `None`, `Never` or `NoReturn` will be a bottom value 
in Swift. "Bottom or not" is not a matter of "implementation", it's a 
conceptual issue. A function returns 'bottom' if and only if it does not return 
at all: that's the definition of 'bottom'.

func foo() -> NoReturn {
let x = fatalError("crash please")
print("1+1=2")
return x
}

The foo-function above will print "crash please" and crash, "1+1=2" will not be 
printed, because `fatalError` is a bottom-value. a @noreturn-function by 
definition returns a bottom value, and bottom shouldn't look like a normal 
type, and IMHO it shouldn't even have a name. So `@noreturn` looks fine to me.

-Michael

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Антон Жилин via swift-evolution]

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 nothing can confirm to, but
approach with empty enum seems more natural to me, because it does not
require any extra work from the compiler.

- Anton

2016-06-05 23:54 GMT+03:00 T.J. Usiyan :

> *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 PM, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> 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), 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.
>>
>> Or "Nothing" as in Scala.
>>
>> > On Jun 5, 2016, at 8:26 PM, Антон Жилин via swift-evolution <
>> swift-evolution@swift.org> 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 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.
>> >
>> > Example 1.
>> > let x: None?
>> > // ...
>> > let y = x!
>> >
>> > It will trap in runtime not because we discover scary bottom thing, as
>> in Haskell, but because x had value Optional.none at that moment and we
>> asserted otherwise.
>> > We could prove that it is always true in this case, but compiler must
>> be stupid about this.
>> >
>> > Example 2.
>> > Compiler should allow including None in structures. Error will show up
>> in constructor, when we will not be able to initialize the field.
>> >
>> > Example 3.
>> > None in an enum case makes that case never appear in values of such a
>> type. But compiler can not know about that.
>> >
>> > - Anton
>> > ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[T.J. Usiyan via swift-evolution]

*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 PM, Charlie Monroe via swift-evolution <
swift-evolution@swift.org> 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), 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.
>
> Or "Nothing" as in Scala.
>
> > On Jun 5, 2016, at 8:26 PM, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> 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 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.
> >
> > Example 1.
> > let x: None?
> > // ...
> > let y = x!
> >
> > It will trap in runtime not because we discover scary bottom thing, as
> in Haskell, but because x had value Optional.none at that moment and we
> asserted otherwise.
> > We could prove that it is always true in this case, but compiler must be
> stupid about this.
> >
> > Example 2.
> > Compiler should allow including None in structures. Error will show up
> in constructor, when we will not be able to initialize the field.
> >
> > Example 3.
> > None in an enum case makes that case never appear in values of such a
> type. But compiler can not know about that.
> >
> > - Anton
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

> 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 
 returning None are equivalent to current @noreturn.
>>> 
>>> I think it would be more useful if the compiler allowed `Never` in every 
>>> type context (i.e. whatever type `T` was expected, an expression of type 
>>> `Never` would be allowed), making expressions like the following compile:
>>> 
>>> let unwrapped: Int = optional ?? fatalError("explanation why this must 
>>> not happen")
>>> 
>>> — Pyry
>> 
>> I dunno, I think @noreturn is clearer than any of these. It tells you that 
>> the function… won’t return. None, Never, etc. could be mistaken as a synonym 
>> for Void, whereas @noreturn is pretty hard to miss.
> 
> FWIW, in the rejection of SE-0097, this was what the core team had to say 
> about it:
> 
> 1) For noreturn, the core team prefers to explore a solution where a function 
> can be declared as returning an non-constructable “bottom” type (e.g. an enum 
> with zero cases).  This would lead to something like:
> 
>   func abort() -> NoReturn { … }

Interesting... There are other cases that would exist for which NoReturn seems 
the wrong name... but they knwo better I guess.


> 
> This will require some new support in the compiler, but should flow better 
> through the type system than @noreturn in function composition and other 
> applications.  Joe Groff offered to write a proposal for this.
> 
> — Pyry
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Pyry Jahkola via swift-evolution]

>>> 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 useful if the compiler allowed `Never` in every 
>> type context (i.e. whatever type `T` was expected, an expression of type 
>> `Never` would be allowed), making expressions like the following compile:
>> 
>> let unwrapped: Int = optional ?? fatalError("explanation why this must 
>> not happen")
>> 
>> — Pyry
> 
> I dunno, I think @noreturn is clearer than any of these. It tells you that 
> the function… won’t return. None, Never, etc. could be mistaken as a synonym 
> for Void, whereas @noreturn is pretty hard to miss.

FWIW, in the rejection of SE-0097 
,
 this was what the core team had to say about it:

1) For noreturn, the core team prefers to explore a solution where a function 
can be declared as returning an non-constructable “bottom” type (e.g. an enum 
with zero cases).  This would lead to something like:

func abort() -> NoReturn { … }

This will require some new support in the compiler, but should flow better 
through the type system than @noreturn in function composition and other 
applications.  Joe Groff offered to write a proposal for this.

— Pyry

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

> 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), 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.
> 
> Or "Nothing" as in Scala.

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



> 
>> On Jun 5, 2016, at 8:26 PM, Антон Жилин 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 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.
>> 
>> Example 1.
>> let x: None?
>> // ...
>> let y = x!
>> 
>> It will trap in runtime not because we discover scary bottom thing, as in 
>> Haskell, but because x had value Optional.none at that moment and we 
>> asserted otherwise.
>> We could prove that it is always true in this case, but compiler must be 
>> stupid about this.
>> 
>> Example 2.
>> Compiler should allow including None in structures. Error will show up in 
>> constructor, when we will not be able to initialize the field.
>> 
>> Example 3.
>> None in an enum case makes that case never appear in values of such a type. 
>> But compiler can not know about that.
>> 
>> - Anton
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

> On Jun 5, 2016, at 1:49 PM, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> 
>> 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 notion of a returnable 
> nothingness with its antonym!
> 
> OTOH, "never" is quite unlikely to be a type name in user code, likely pretty 
> googleable, and explains itself quite well in examples like `Result Never>`.
> 
>> 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 useful if the compiler allowed `Never` in every type 
> context (i.e. whatever type `T` was expected, an expression of type `Never` 
> would be allowed), making expressions like the following compile:
> 
> let unwrapped: Int = optional ?? fatalError("explanation why this must 
> not happen")
> 
> — Pyry

I dunno, I think @noreturn is clearer than any of these. It tells you that the 
function… won’t return. None, Never, etc. could be mistaken as a synonym for 
Void, whereas @noreturn is pretty hard to miss.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Pyry Jahkola via swift-evolution]

> 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 notion of a returnable 
nothingness with its antonym!

OTOH, "never" is quite unlikely to be a type name in user code, likely pretty 
googleable, and explains itself quite well in examples like `Result`.

> 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 useful if the compiler allowed `Never` in every type 
context (i.e. whatever type `T` was expected, an expression of type `Never` 
would be allowed), making expressions like the following compile:

let unwrapped: Int = optional ?? fatalError("explanation why this must not 
happen")

— Pyry

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Антон Жилин 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 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.

Example 1.
let x: None?
// ...
let y = x!

It will trap in runtime not because we discover scary bottom thing, as in
Haskell, but because x had value Optional.none at that moment and we
asserted otherwise.
We could prove that it is always true in this case, but compiler must be
stupid about this.

Example 2.
Compiler should allow including None in structures. Error will show up in
constructor, when we will not be able to initialize the field.

Example 3.
None in an enum case makes that case never appear in values of such a type.
But compiler can not know about that.

- Anton
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution