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.mihalko...@gmail.com>
> Date: June 8, 2016 at 7:49:22 AM GMT+2
> To: Thorsten Seitz <tseit...@icloud.com>
> Cc: Michael Peternell <michael.petern...@gmx.at>, swift-evolution
> <swift-evolut...@swift.org>, Dave Abrahams <dabrah...@apple.com>, Douglas
> Gregor <dgre...@apple.com>, Joe Groff <jgr...@apple.com>
> Subject: Re: [swift-evolution] [Draft] Change @noreturn to unconstructible
> return type
>
>
>> On Jun 8, 2016, at 6:57 AM, Thorsten Seitz <tseit...@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-evolut...@swift.org>:
>>>>
>>>>
>>>> Am 07.06.2016 um 22:14 schrieb L Mihalkovic via swift-evolution
>>>> <swift-evolut...@swift.org>:
>>>>
>>>>
>>>>>> On Jun 7, 2016, at 9:49 PM, Michael Peternell via swift-evolution
>>>>>> <swift-evolut...@swift.org> wrote:
>>>>>>
>>>>>>
>>>>>>>> Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution
>>>>>>>> <swift-evolut...@swift.org>:
>>>>>>>>
>>>>>>>> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution
>>>>>>>> <swift-evolut...@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)
>
>
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
