Proposal: add some more 'smarts' to literals of types using empty struct{}

[splace]

I'm not sure if this doesn't have some nasty drawback, but I have thought about it several times and would like to share it for your consideration.

Basically its about being able to miss out typing 'struct{}' in literals where its unambiguous.
(i did try making a value and naming it, say 'Nothing := struct{}{} ', but that’s still not great.)

Case 1

a few times, i have composed with types that have no state themselves, say; they implement some default static behaviour to meet an interface.

type Opaque struct{}

func (o Opaque) isOpaque() bool {
	return true
}

currently, when made literally, you need to specify the empty struct, which seems a bit redundant/unclear, or use named parameters which often results in stuttering.

type OpaqueColor struct{
        Color
        Opaque
}

c:=OpaqueColor{Color{},struct{}}

or

c:=OpaqueColor{Color:Color{}}

clearer?

c:=OpaqueColor{Color{}}

imagine if you had several empty types.

case 2.

when you use a map with empty structs values, say to make a set, the literal can get a bit bloated;
(code below cut/paste from a web search.)

cc := &dockerclient.ContainerConfig{
    // ...
    Volumes: map[string]struct{}{
        "foo": struct{}{},
        "bar": struct{}{},
   },
}

clearer?

cc := &dockerclient.ContainerConfig{
    // ...
    Volumes: map[string]{"foo","bar"},
}

also, if you change to/from a slice of strings its trivial to update the literal.

case 3

using channels of empty struct{}

done := make(chan struct{})
// ...
done <- struct{}{}

i think this is neater, since empty struct types are all the same anyway

done <- {}

[davecheney]

In case 1, if you have several differently named empty types, their zero values is identical to their initialised value, so you can initialise them, or not initialise them and the results is the same.

Case 2 and 3. Remember that go optimises for the reader by reducing the number of different ways to represent the same syntax. I'd suggest either

var stop struct{}
done <- stop

or

done := make(chan int)
done <- 0

as an unbuffered channel of an int and an unbuffered channel of a struct{} consume the same amount of space.

[pciet]

These cases are in my mind not taking full advantage of Go.

• empty struct types to satisfy an interface indicate that the interface isn’t designed well
• sets are better represented as a slice
• for readability type Signal struct{} could be used

[splace]

In case 1, if you have several differently named empty types, their zero values is identical to their initialised value, so you can initialise them, or not initialise them and the results is the same.

so;

c:=OpaqueColor{Color{},Opaque{}}

or

var o Opaque
c:=OpaqueColor{Color{},o}

[splace]

as an unbuffered channel of an int and an unbuffered channel of a struct{} consume the same amount of space.

where is the int's value held then?

[splace]

sets are better represented as a slice

i think of sets as something you cant have duplicates in, because that is what you are representing.

[davecheney]

Neither,

var c OpaqueColor

[splace]

Neither,

var c OpaqueColor

the empty Color type is just to save me typing, assume it wouldn't always be empty. this is about literals.

[davecheney]

the empty Color type is just to save me typing, assume it wouldn't always be empty

There is no value (ha!) in explicitly initialising a field with an underlying type of struct{}. You don't need to do it, so it shouldn't be necessary to change the language to make that operation less verbose.

[jimmyfrasche]

cases 2 and 3 would be handled by #12854 which is more general

[splace]

There is no value (ha!) in explicitly initialising a field with an underlying type of struct{}. You don't need to do it, so it shouldn't be necessary to change the language to make that operation less verbose.

reply confuses me;

assume in all previous examples Color has a non-default value, say Color{1,2,3} or something

c:=OpaqueColor{Color{1,2,3},struct{}}

or

c:=OpaqueColor{Color:Color{1,2,3}}

[splace]

cases 2 and 3 would be handled by #12854 which is more general

very close, it think it would leave the colon and empty braces in 2, but sure near enough.

[davecheney]

@splace you don't need to initialise fields with an underlying type of struct{}, there is no way you can initialise it in a way that is distinguishable from the field's zero value.

[splace]

@davecheney which is what i'm looking for, example?