struct{} literal

[roger peppe]

On 19 January 2012 15:32, Brad Fitzpatrick <brad...@golang.org> wrote:
>
>
> On Thu, Jan 19, 2012 at 7:32 AM, Brad Fitzpatrick <brad...@golang.org>
> wrote:
>>
>> On Thu, Jan 19, 2012 at 7:30 AM, <dvy...@google.com> wrote:
>>>
>>> On 2012/01/19 15:22:00, dvyukov wrote:
>>>>
>>>> On Thu, Jan 19, 2012 at 7:15 PM, Brad Fitzpatrick
>>>
>>> <brad...@golang.org>wrote:
>>>
>>>> > I'm curious how this came up. Did you actually have a program where
>>>
>>> copy
>>>>
>>>> > zero-sized values around was noticeable?  :-)
>>>
>>>
>>>> Yes, it is a synthetic benchmark for something else :) I've noticed a
>>>
>>> weird
>>>>
>>>> difference in performance I can't explain when I assign 42 and
>>>
>>> struct{} to
>>>>
>>>> interface{}. For 42 specialized type algorithm kicks in, for struct{}
>>>
>>> it
>>>>
>>>> does not and so it is 2 times slower while the object is actually
>>>> infinitely smaller.
>>>
>>>
>>> Btw, currently struct{} maps to AMEM0, so it's possible to define
>>> map[struct{}]int which makes very little sense (most likely a
>>> programming error). Don't we want to do something with it?
>>
>>
>> map[string{}]int is actually kinda cool:  you can think of it as an
>> integer that may not be set.
>
>
> er, map[struct{}]int, rather

here's a digression:
struct{} is becoming rather common and useful (particularly
as a channel element type). i wonder how people feel about
the possiblity of allowing nil as a struct{} literal - struct{}{} is somewhat
clumsy.

e.g.

struct{}{} == nil (would be true)
var x struct{} = nil (redundant but valid initialiser)
c := make(chan struct{}, 99); c <- nil

[Rob 'Commander' Pike]

Not now.

-rob

[Gustavo Niemeyer]

> wonder how people feel about
> the possiblity of allowing nil as a struct{} literal - struct{}{} is somewhat
> clumsy.

Probably not worth it. I've never spelled struct{}{} myself, to be honest.

> struct{}{} == nil (would be true)

There's no point in comparing a struct{} to another struct{}.

> var x struct{} = nil  (redundant but valid initialiser)

That's: var x struct{}

> c := make(chan struct{}, 99); c <- nil

That's the only legitimate case, and it's spelled nicely enough with:

var nothing struct{}
c <- nothing

--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.

[roger peppe]

On 19 January 2012 16:17, Gustavo Niemeyer <gus...@niemeyer.net> wrote:
>> wonder how people feel about
>> the possiblity of allowing nil as a struct{} literal - struct{}{} is somewhat
>> clumsy.
>
> Probably not worth it. I've never spelled struct{}{} myself, to be honest.
>
>> struct{}{} == nil    (would be true)
>
> There's no point in comparing a struct{} to another struct{}.
>
>> var x struct{} = nil  (redundant but valid initialiser)
>
> That's: var x struct{}
>
>> c := make(chan struct{}, 99); c <- nil
>
> That's the only legitimate case, and it's spelled nicely enough with:
>
> var nothing struct{}
> c <- nothing

agreed. but i know that i usually use chan bool rather than
chan struct{} just because it's more convenient to do
x <- true rather than x <- struct{}{}.

the latter better represents a situation when the presence of a value
is significant, not its contents (and for buffered channels and maps,
it's potentially quite a bit more efficient) so i wondered if a little
bit of sugar might make it easier to prefer.

perhaps, as you suggest, i should just get into the habit of writing:

var empty struct{}

(or "nothing", or even "null")

[Nigel Tao]

On 20 January 2012 02:40, roger peppe <rogp...@gmail.com> wrote:
> struct{}{} == nil    (would be true)
> var x struct{} = nil  (redundant but valid initialiser)
> c := make(chan struct{}, 99); c <- nil

An alternative proposal is to make _ more like /dev/zero than /dev/null:

var x struct{} = _
var y int = _
func f() (bool, string, io.Reader) {

c := make(chan struct{}, 99)

c <- _
return _, _, _
}

However, as Rob said: not now.