The constraint can't be used for phantom types. If C is an interface
with an empty type list and P is given by
    type P(type T C) struct{}
you can't instantiate P because no type can satisfy C.

C is not the type with 0 inhabitants: it's a constraint on types that
cannot be satisfied.

I don't see how it can be used in any valid program or why it would be
hard to detect. I am a little fuzzy on when type lists bring the
underlying type into play, though.

On Thu, Jun 18, 2020 at 1:17 PM Axel Wagner
<axel.wagner...@googlemail.com> wrote:
>
> Addendum: In Go, every type needs to be inhabited by at least one value - 
> it's zero value. And we already have a type that can take *exactly* one 
> value, namely struct{}.
>
> On Thu, Jun 18, 2020, 22:13 Axel Wagner <axel.wagner...@googlemail.com> wrote:
>>
>> These arguments would be more convincing, if Go wouldn't already reject 
>> interfaces impossible to implement: https://play.golang.org/p/dYm8js26qml
>>
>> On Thu, Jun 18, 2020, 17:26 Jesper Louis Andersen 
>> <jesper.louis.ander...@gmail.com> wrote:
>>>
>>> It is a type which cannot be inhabited by a term. These exist and often 
>>> have uses. As Bryan wrote they also completes the type lattice, so 
>>> rejecting them is often a lot of work for little gain.
>>>
>>> If you want examples, look up phantom types, where an uninhabited type is 
>>> used as a tag for ensuring compile time restrictions.
>>>
>>> On Wed, Jun 17, 2020, 22:09 jimmy frasche <soapboxcic...@gmail.com> wrote:
>>>>
>>>> This isn't a bug per se, but I can file one if requested.
>>>>
>>>> https://go2goplay.golang.org/p/AWynhg6ya7h
>>>>
>>>> Since embedding interfaces with type lists uses the intersection of
>>>> the items in the type list, it's possible to create an interface that
>>>> cannot be satisfied by any type.
>>>>
>>>> Currently this does not cause an error until you attempt to
>>>> instantiate something that uses such an interface as a bound.
>>>>
>>>> I think it would be more useful to raise the error when defining the
>>>> interface that cannot be used as it's likely an error—or at least I
>>>> can see no valid use for creating an unsatisfiable constraint.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups 
>>>> "golang-nuts" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>>> email to golang-nuts+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/golang-nuts/CANG3jXJt_n1HrRMV1SBcaurXOrXVJxXrKN_F%3DtgMAcMJ%2BPOLcg%40mail.gmail.com.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to golang-nuts+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVPP21fky2qcgfnAYjH6H047C1A0Y_V%3Doa%3DB3pTWRX68g%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANG3jX%2BESnanNyPBdDdQdc_uZMFzU-h3fMRGqB01M-RJVtnSaQ%40mail.gmail.com.

Reply via email to