If you carelessly do anything, you can introduce bugs. Also note that it is fairly easy in Go to construct immutable "values".
The only thing we do not have is immutable value holders (let in other languages) which is a form of static single assignment at the language level. The concept of variable is actually much more "functional" funnily enough, but I digress. Just don't be careless and you should be fine. I have a hard time seeing why someone would want to assign a new value to a package level error variable. Maybe you have a specific idea/example in mind? On Saturday, August 6, 2016 at 1:08:56 PM UTC+2, T L wrote: > > > > 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.
