On the other hand, I would like to see introduced some variant of slices with immutable backing arrays (it will allocate a lot though to modify a variable of that type) that would be comparable. That's a whole other topic however. slices are a much more delicate concept.
On Saturday, August 6, 2016 at 2:37:40 PM UTC+2, atd...@gmail.com wrote: > > 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.
