On Saturday, August 6, 2016 at 11:53:42 AM UTC+2, T L wrote: > > > > On Saturday, August 6, 2016 at 5:45:50 PM UTC+8, atd...@gmail.com wrote: >> >> No, I'm saying that the current implementation is two pointers. >> The value is addressed by the second pointer. So you cannot really put a >> const in an interface. (thought experiment) >> >> Of course, in the specific case of boxing a value type, that could work. >> If you accept that the *typ never changes throughout the program. >> > > for constant intrfaces, the *typ property is not needed. Calling of their > methods will confirmed at compile time. > You need it, the interface cannot be of any type, it would need to be initialized with a value of a given type for method dispatch. The only thing is that the method dispatch would be fixed. (again a thought experiment :)
That's similar to sync.Value ( https://golang.org/pkg/sync/atomic/#Value) > > >> >> The question is, why a special case, what would you use it for? >> sync.Pools ? >> >> If it's just for error variables to be constants, maybe it is not worth >> it. What problem does it solve ? >> > > for safety. > What is trhe safety issue? Do you have an example at hand? > > >> >> On Saturday, August 6, 2016 at 11:11:24 AM UTC+2, T L wrote: >>> >>> >>> >>> On Saturday, August 6, 2016 at 4:06:07 PM UTC+8, atd...@gmail.com wrote: >>>> >>>> Possibily, if you freeze the type of things that can be boxed by the >>>> interface. But what would it be useful for ? >>>> That would just mean that an interface is constant. Not even that the >>>> value it wraps can't be changed (because with the current implementation, >>>> the values an interface wraps need to be addressable). >>>> >>> >>> you mean a value should be addressable to let an interface wraps wrap it? >>> Not true, "_ = interface{}(1)" is valid in current implementation. >>> >>> >>>> >>>> >>>> >>>> On Saturday, August 6, 2016 at 9:53:26 AM UTC+2, T L wrote: >>>>> >>>>> Is it possible to make an interface constant if its concrete value >>>>> type is bool/number/string? >>>>> >>>>> On Saturday, August 6, 2016 at 3:48:17 AM UTC+8, Ian Lance Taylor >>>>> wrote: >>>>>> >>>>>> On Fri, Aug 5, 2016 at 11:21 AM, T L <tapi...@gmail.com> wrote: >>>>>> > >>>>>> > For an interface value, its internal values will never change. >>>>>> > Are there any problems if golang supports constant interface >>>>>> values? >>>>>> >>>>>> Pedantically, in Go, constants are untyped by default. It doesn't >>>>>> make sense to speak of an untyped interface value. I would describe >>>>>> what you are asking for as an immutable variable. I've often thought >>>>>> that immutable variables would be useful in Go, but since they have >>>>>> to >>>>>> be initialized it's not that simple. For example, io.EOF is >>>>>> initialized using a function call. That means that it can't actually >>>>>> be in read-only memory, and of course it's possible to take it's >>>>>> address. How do we prevent it from being changed, without >>>>>> introducing >>>>>> an immutable qualifier into the type system? It's a complex problem >>>>>> for which I have no solution. And the benefits of an immutable >>>>>> variable aren't all that high. >>>>>> >>>>>> 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.
