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.
>
> 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.
>
> 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.
