On Mon, Feb 25, 2019 at 4:17 PM Louki Sumirniy <louki.sumirniy.stal...@gmail.com> wrote: > > It didn't occur to me until I was thinking about the issues raised in > constructing a bundle of compound literals to define the parameters for > multi-command CLI applications that such declarations really have to be > sanitised just like any untrusted input. In some cases the errors may be > entirely trivial and not able to cause unintended effects later on, but > anything less than an exhaustive validation could conceal a serious security > hole potentially for a very long time. And thus also, should such mechanisms > be built into the language, they have to be likewise as stringently checked.
When it comes to the Go language, I don't think the issues you are describing here are related to generics. Go has a clear and precise definition for compound literals and for variables with no initializers. That same definition would be applied to generic code. We don't need to treat them any differently in generic code. To put it another way, it's worth discussing the fact that Go has a zero value for every type, and that the uninitialized value of any type is given that zero value, but this is a general issue in the language, not related to generics. And while it's worth discussing it's very very unlikely to change in future versions of Go. 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.
