On Saturday, August 6, 2016 at 6:04:00 PM UTC+8, atd...@gmail.com wrote: > > > > 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? > If you carelessly change the value of a global variable in std lib, some hard found bugs will be created. > >> >>> >>> 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.
