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

[L. Mihalkovic]

I realize that this message might have more relevance in this list. Let me know if that is not the case.

Begin forwarded message:

> From: L Mihalkovic <laurent.mihalkovic at gmail.com>
> Date: June 8, 2016 at 7:49:22 AM GMT+2
> To: Thorsten Seitz <tseitz42 at icloud.com>
> Cc: Michael Peternell <michael.peternell at gmx.at>, swift-evolution <swift-evolution at swift.org>, Dave Abrahams <dabrahams at apple.com>, Douglas Gregor <dgregor at apple.com>, Joe Groff <jgroff at apple.com>
> Subject: Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type
> 
> 
>> On Jun 8, 2016, at 6:57 AM, Thorsten Seitz <tseitz42 at icloud.com> 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 <swift-evolution at swift.org>:
>>>> 
>>>> 
>>>> Am 07.06.2016 um 22:14 schrieb L Mihalkovic via swift-evolution <swift-evolution at swift.org>:
>>>> 
>>>> 
>>>>>> On Jun 7, 2016, at 9:49 PM, Michael Peternell via swift-evolution <swift-evolution at swift.org> wrote:
>>>>>> 
>>>>>> 
>>>>>>>> Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution <swift-evolution at swift.org>:
>>>>>>>> 
>>>>>>>> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at 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. 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.
>>> 
> 
> Consider for a moment that the bottom type is a technical aspect of the runtime., the thing that the compiler needs so avoid some internal magic while steering towards expressing more things that can be expressed with protocols, using protocols. So that would give the compiler what it needs to have more internal symmetry. But then nothing says that our needs are the same as the compiler’s, particularly when it comes to expressivity. So that leaves us with the possibility of having a bottom type, and having something based on it that can present a more user friendly interface. And while we are at it, nothing says that the user facing side has to be universal, fitting all possible use cases. So then that opens up the possibility of 
> 
> 1) have a bottom type
> 2) have use site derived notions (the ones we users will learn) that are internally linkable to 1), but outside of what we care about
> 
> which bring us back to something like the following scenario:
> 
> 1)  create a  protocol SwiftBottomType { }   [  the core team might defend the idea that it should really be BuiltinBottomType, but the argument also goes that BuiltinXxxxLiteral can be converted to SwiftXxxxLiteral  ]. This is something only the compiler cares about, but a building block for what we need. it would be simple to enforce in the compiler that SwiftXXXXX protocols cannot be the target of any user defined conformances if need be. 
> In fact, these SwiftXxxxxx protocols could be considered so critical for the existence of the language/compiler (i.e. ‘below' the stdlib) that might might not even be represented in the sodlib, but directly manufactured into the TEXT.__swift3_builtin (don’t quote me on this one versus the meaning of the __swift2_proto??? can't recall its name at the moment) section of the libswiftRuntime.a (runtime lib already deals with all the metadata loading, low level existential, and internal reflection)
> 
> then :
> BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_(BuiltinBooleanLiteralConvertible)
> BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_(BuiltinExtendedGraphemeClusterLiteralConvertible)
> BUILTIN_LITERAL_CONVERTIBLE_PROTOCOL_(BuiltinFloatLiteralConvertible)
> ...
> 
> can become (or stay as it is but, the point is that they are unified, and have become a pattern for future extensibility)
> 
> BUILTIN_CORE_PROTOCOL_(SwiftBooleanLiteralConvertible)  // btw, they can all retain the BuiltinXxxxxxxx pattern
> BUILTIN_CORE_PROTOCOL_(SwiftExtendedGraphemeClusterLiteralConvertible)
> BUILTIN_CORE_PROTOCOL_(SwiftFloatLiteralConvertible)
> BUILTIN_CORE_PROTOCOL_(SwiftBottomType)		// one of the the new guys
> 
> 
> 2) then create  a  enum NoReturn: SwiftBottomType {}  that we learn about (and name it Never, or …. to match the returning situation. And as time goes, there may be other synonymous that will be built with the best possible user facing name for these circumstances.
> 
> 
> When looking at this question and a couple of other related ones, a pattern should form, whose rational is self evident (I am listing a couple others in a separate doc just because IMHO it is a somewhat elegant binding for the low level)
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160608/460cc9b3/attachment.html>