On Thu, Sep 6, 2018 at 2:32 PM, <alan.f...@gmail.com> wrote: > > Here's a few points which I noticed when reading through the draft design > which I thought people might have trouble getting their heads around: > > 1. The use of untyped numeric constants where you might need to specify the > exact value needed to get the thing to work. I don't think anyone could > describe that as obvious. > > 2. The inability to specify in a simple way that a method doesn't have a > return value, can take a variable number of arguments or (a particularly > nasty one) to distinguish a method call from a struct field of function > type. I thought folks might thrash around quite a bit trying to figure these > out before they released they'd have to use a conversion to a suitable > interface type. > > 3. The difficulty of distinguishing between methods which take a value and a > pointer receiver. > > 4. The 'nil' value problem. In C# they overload the 'default' keyword (i.e. > default(T)) to produce the default value (all bits set to zero) for a type > T. Maybe we could do something like this?
Thanks for the list. Ian -- 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. For more options, visit https://groups.google.com/d/optout.
