Re: [go-nuts] Re: Ideas for a Go interpeter, feedback requested

[Jason E. Aten]

I don't know if there is still interest in this project, but I continue to 
be interested. Recently I note that Apple's Swift might reasonably be a 
good target.

Consider:

a. swift already provides a repl, with debugger. quite possibly easy access 
to existing scientific C/C++ codebase, which Seb was hoping for.

b. there is the ability to call into Go from Swift, using gomobile. 
https://medium.com/@rakyll/calling-go-from-swift-be88709942c3#.30mhs3whh

c. swift provides protocols, which appear to generalize interfaces.

d. these libraries can be used to add goroutines, channels, select, defer, 
and panic to swift:

https://github.com/tidwall/GoSwift

https://github.com/tidwall/Safe


e. swift supports multiple returns in a tuple; swift supports closures.


f. there is already a production quality JIT-compiler provided for you 
(e.g. it leverages llvm); this is what the swift REPL utilizes.



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

Re: [go-nuts] Re: Go package management proposal process

[Rob Pike]

I would like to propose a cloture vote to abrogate the need to entable a
veto to the de facto habeas corpus motion that is de jure blocking progress
on this endeavor.

Or else just get on with it.

-rob


On Sun, Aug 7, 2016 at 4:24 AM, Peter Bourgon  wrote:

> Ah! Ha. All good.
>
> On Sat, Aug 6, 2016 at 17:51 'Jessica Frazelle' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> Sorry Peter that got stuck in moderation I wrote it before your other
>> message
>>
>> On Saturday, August 6, 2016, Peter Bourgon  wrote:
>>
>>> Again, there is no nomination process for the committee right now.
>>> Please don't propose yourself or others.
>>> On Sat, Aug 6, 2016 at 17:11 'Jessica Frazelle' via golang-nuts <
>>> golang-nuts@googlegroups.com> wrote:
>>>
 +1 to Dave Cheney.

 I agree we need as simple a solution as possible.

 I propose myself for the working group. I have dealt with the vendoring
 in the docker project as well as medium to small sized projects and most
 currently in kubernetes.

 If elected, my platform will fight to make vendoring as simple and
 seamless to use as the tool we love so much, gofmt.

 Let's stop the madness of jumping 3 steps ahead, and arguing in
 circles. Let's solve the problems from ground zero. Starting with a problem
 statement.

 Make go vendoring great again (wait... great for the first time ;).

 Jess

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

>>>
>>
>> --
>>
>>
>> Jessie Frazelle
>> 4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
>> pgp.mit.edu
>> 
>>
>> --
>> 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.
>>
> --
> 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.
>

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

Re: [go-nuts] How long are the results from runtime.Callers valid?

[Carl Mastrangelo]

Cgo is not in use; thank you for the quick response!

On Saturday, August 6, 2016 at 11:49:22 AM UTC-7, Ian Lance Taylor wrote:
>
> On Sat, Aug 6, 2016 at 10:08 AM, Carl Mastrangelo 
>  wrote: 
> > TL;DR:  Is the uintptr slice returned from runtime.Callers always valid? 
> > 
> > Reading the docs* for runtime.Callers says: "Callers fills the slice pc 
> with 
> > the return program counters of function invocations on the calling 
> > goroutine's stack. "  Does this imply that once the goroutine is gone, 
> or 
> > all the functions have returned, the uintptrs could be pointing to 
> garbage? 
> > 
> > I ask because I would like a cheap-ish stacktrace for some error 
> handling 
> > code I am writing, and I don't want to turn the stack frame into a full 
> > string.  If I can capture the functions on the stack and maybe turn them 
> > into an error message later that would be ideal. 
>
> The pointers are always valid.  All executable code is created at 
> compilation time, and the function pointers returned by 
> runtime.Callers always point into executable code that is always 
> present. 
>
> (An exception would be if you used runtime.SetCgoTraceback to collect 
> a C function address that happens to be in a shared library that you 
> happened to dlclose.  But if you don't use SetCgoTraceback or you 
> don't dlopen and then dlclose C shared libraries, this won't be a 
> problem.) 
>
> 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.

Re: [go-nuts] How long are the results from runtime.Callers valid?

[Ian Lance Taylor]

On Sat, Aug 6, 2016 at 10:08 AM, Carl Mastrangelo
 wrote:
> TL;DR:  Is the uintptr slice returned from runtime.Callers always valid?
>
> Reading the docs* for runtime.Callers says: "Callers fills the slice pc with
> the return program counters of function invocations on the calling
> goroutine's stack. "  Does this imply that once the goroutine is gone, or
> all the functions have returned, the uintptrs could be pointing to garbage?
>
> I ask because I would like a cheap-ish stacktrace for some error handling
> code I am writing, and I don't want to turn the stack frame into a full
> string.  If I can capture the functions on the stack and maybe turn them
> into an error message later that would be ideal.

The pointers are always valid.  All executable code is created at
compilation time, and the function pointers returned by
runtime.Callers always point into executable code that is always
present.

(An exception would be if you used runtime.SetCgoTraceback to collect
a C function address that happens to be in a shared library that you
happened to dlclose.  But if you don't use SetCgoTraceback or you
don't dlopen and then dlclose C shared libraries, this won't be a
problem.)

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.

Re: [go-nuts] Re: Go package management proposal process

[Peter Bourgon]

Ah! Ha. All good.
On Sat, Aug 6, 2016 at 17:51 'Jessica Frazelle' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Sorry Peter that got stuck in moderation I wrote it before your other
> message
>
> On Saturday, August 6, 2016, Peter Bourgon  wrote:
>
>> Again, there is no nomination process for the committee right now. Please
>> don't propose yourself or others.
>> On Sat, Aug 6, 2016 at 17:11 'Jessica Frazelle' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>>> +1 to Dave Cheney.
>>>
>>> I agree we need as simple a solution as possible.
>>>
>>> I propose myself for the working group. I have dealt with the vendoring
>>> in the docker project as well as medium to small sized projects and most
>>> currently in kubernetes.
>>>
>>> If elected, my platform will fight to make vendoring as simple and
>>> seamless to use as the tool we love so much, gofmt.
>>>
>>> Let's stop the madness of jumping 3 steps ahead, and arguing in circles.
>>> Let's solve the problems from ground zero. Starting with a problem
>>> statement.
>>>
>>> Make go vendoring great again (wait... great for the first time ;).
>>>
>>> Jess
>>>
>>> --
>>> 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.
>>>
>>
>
> --
>
>
> Jessie Frazelle
> 4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
> pgp.mit.edu
> 
>
> --
> 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.
>

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

[go-nuts] How long are the results from runtime.Callers valid?

[Carl Mastrangelo]

TL;DR:  Is the uintptr slice returned from runtime.Callers always valid?

Reading the docs* for runtime.Callers says: "Callers fills the slice pc 
with the return program counters of function invocations on the calling 
goroutine's stack. "  Does this imply that once the goroutine is gone, or 
all the functions have returned, the uintptrs could be pointing to 
garbage?   

I ask because I would like a cheap-ish stacktrace for some error handling 
code I am writing, and I don't want to turn the stack frame into a full 
string.  If I can capture the functions on the stack and maybe turn them 
into an error message later that would be ideal.

Example (requires 1.7): https://play.golang.org/p/bfZBvcLzje

* https://tip.golang.org/pkg/runtime/#Callers

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

Re: [go-nuts] Is this an acceptable way to handle errors

[Ian Lance Taylor]

On Sat, Aug 6, 2016 at 5:50 AM, GoNutter  wrote:
>
> I have a number of cases where I have to handle typed errors. I have been
> doing this previoiusly
>
> err :=SomeFunctionCall()
> if err != nil{
>   switch e := err.(type){
> case sometype:
>//do something
> case someothertype:
>//do something else
> default:
>//do default
>   }
> }
>
> However, it occurred to me that I can just do this...
>
> err :=SomeFunctionCall()
>   switch e := err.(type){
> case nil:
>break
> case sometype:
>//do something
> case someothertype:
>//do something else
> default:
>//do default
> }
>
>
> I guess this will be less efficient because it will involve some reflection
> in cases where I imagine the initial check that error is not nil will be
> less expensive. Is this correct?

No, not really.  The check for err == nil is pretty much the same as
the initial check in the type switch.  There might be an extra branch
instruction in the type switch, I'm not sure, but I expect it would be
negligible in practice.

> Apart from this, is there any other reason that this would not be a
> recommended way to handle the nil error case?

It's more idiomatic Go to write err != nil, so other people reading
your code may find it a bit surprising.  Only you can judge how
important that is for you.

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.

Re: [go-nuts] Why can't interface value be constant?

[Ian Lance Taylor]

On Sat, Aug 6, 2016 at 4:08 AM, T L  wrote:
>
> If you carelessly change the value of a global variable in std lib, some
> hard found bugs will be created.

This is what you really want, and it is the reason I was talking about
immutable variables earlier.

In Go, a constant is created at compile time and always has that
value.  You started this thread talking about the io.EOF variable.
The io.EOF variable is initialized with a function call.  It is
written in the source code in io/io.go as

var EOF = errors.New("EOF")

In Go, it does not make sense to speak about a constant that is
initialized from a function call.  Constants are set at compile time,
so when would that function call run?

If you look at the implementation of errors.New, you will see that it
returns a pointer.  So even if you somehow decide that the result of
errors.New is a constant, what you have is a constant pointer.  That
says nothing about the value to which the pointer points.  Even if you
described the pointer as a Go const, the value to which the pointer
points could still be changed, so the overall meaning of the value can
change.  So it's not enough to speak about a constant value.  You have
to speak about a constant value that points to another constant value.
Of course, you can't take the address of a constant in Go--if you
could, you could change its value.  So once again we are back to
talking about immutability.

It's easy to say the words "constant interface value."  In the context
of a programming language, you need to think about what those words
really mean and how they would be implemented.

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.

Re: [go-nuts] Re: Go package management proposal process

[Peter Bourgon]

Again, there is no nomination process for the committee right now. Please
don't propose yourself or others.
On Sat, Aug 6, 2016 at 17:11 'Jessica Frazelle' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> +1 to Dave Cheney.
>
> I agree we need as simple a solution as possible.
>
> I propose myself for the working group. I have dealt with the vendoring in
> the docker project as well as medium to small sized projects and most
> currently in kubernetes.
>
> If elected, my platform will fight to make vendoring as simple and
> seamless to use as the tool we love so much, gofmt.
>
> Let's stop the madness of jumping 3 steps ahead, and arguing in circles.
> Let's solve the problems from ground zero. Starting with a problem
> statement.
>
> Make go vendoring great again (wait... great for the first time ;).
>
> Jess
>
> --
> 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.
>

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

[go-nuts] How to call test/benchmark code from main

[Tong Sun]

I know that golang test/benchmark code are invoked by `go test`, but I'm 
wondering how I can invoke them explicitly in my own main() function?

The reason I'm asking is that for those packages that don't provide any 
sample code, their test code is the closest thing I can dipped into to turn 
them into my own sample code. So I need a strategy as simple as possible to 
do it. 

If you'd say that the answer is case-by-case, then it is 
the https://github.com/ekzhu/go-sql-lsh/blob/master/sqlite_benchmark_test.go 
that I'm talking about. 

Thanks


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

[go-nuts] Re: Go package management proposal process

['Jessica Frazelle' via golang-nuts]

+1 to Dave Cheney.

I agree we need as simple a solution as possible.

I propose myself for the working group. I have dealt with the vendoring in the 
docker project as well as medium to small sized projects and most currently in 
kubernetes. 

If elected, my platform will fight to make vendoring as simple and seamless to 
use as the tool we love so much, gofmt. 

Let's stop the madness of jumping 3 steps ahead, and arguing in circles. Let's 
solve the problems from ground zero. Starting with a problem statement. 

Make go vendoring great again (wait... great for the first time ;).

Jess

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

[go-nuts] Is this an acceptable way to handle errors

[GoNutter]

Hi,

I have a number of cases where I have to handle typed errors. I have been 
doing this previoiusly

err :=SomeFunctionCall()
if err != nil{
  switch e := err.(type){
case sometype:
   //do something
case someothertype:
   //do something else
default:
   //do default
  }
}

However, it occurred to me that I can just do this...

err :=SomeFunctionCall()
  switch e := err.(type){
case nil:
   break
case sometype:
   //do something
case someothertype:
   //do something else
default:
   //do default
}


I guess this will be less efficient because it will involve some reflection 
in cases where I imagine the initial check that error is not nil will be 
less expensive. Is this correct?

Apart from this, is there any other reason that this would not be a 
recommended way to handle the nil error case?

Many thanks

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

Re: [go-nuts] Why can't interface value be constant?

[atd...@gmail.com]

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

Re: [go-nuts] Why can't interface value be constant?

[atd...@gmail.com]

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

Re: [go-nuts] Why can't interface value be constant?

[T L]

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

Re: [go-nuts] Why can't interface value be constant?

[atd...@gmail.com]

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

Re: [go-nuts] Why can't interface value be constant?

[T L]

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

Re: [go-nuts] Why can't interface value be constant?

[Dave Cheney]

Interfaces don't describe data, they describe behaviour. If you don't want 
the behaviour to be changeable, use a concrete type.

On Saturday, 6 August 2016 19:30:22 UTC+10, T L wrote:
>
>
>
> On Saturday, August 6, 2016 at 5:19:08 PM UTC+8, Dave Cheney wrote:
>>
>> Because an interface is a run time data structure, it cannot contain 
>> constants because they don't exist at run time.
>>
>
> I think an interface is not essential to be always a run time data 
> structure. If compiler thinks it is constant, then it is constant.
>  
>
>>
>> On Saturday, 6 August 2016 19:14:26 UTC+10, T L wrote:
>>>
>>>
>>>
>>> On Saturday, August 6, 2016 at 3:58:52 PM UTC+8, Dave Cheney wrote:

 It is not possible. Constants only exist at compile time.
>>>
>>>
>>> yes, but why constant interface values can't exist at compile time?
>>>  
>>>
>>  
>

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

Re: [go-nuts] Why can't interface value be constant?

[T L]

On Saturday, August 6, 2016 at 5:19:08 PM UTC+8, Dave Cheney wrote:
>
> Because an interface is a run time data structure, it cannot contain 
> constants because they don't exist at run time.
>

I think an interface is not essential to be always a run time data 
structure. If compiler thinks it is constant, then it is constant.
 

>
> On Saturday, 6 August 2016 19:14:26 UTC+10, T L wrote:
>>
>>
>>
>> On Saturday, August 6, 2016 at 3:58:52 PM UTC+8, Dave Cheney wrote:
>>>
>>> It is not possible. Constants only exist at compile time.
>>
>>
>> yes, but why constant interface values can't exist at compile time?
>>  
>>
>  

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

Re: [go-nuts] Why can't interface value be constant?

[Dave Cheney]

Because an interface is a run time data structure, it cannot contain 
constants because they don't exist at run time.

On Saturday, 6 August 2016 19:14:26 UTC+10, T L wrote:
>
>
>
> On Saturday, August 6, 2016 at 3:58:52 PM UTC+8, Dave Cheney wrote:
>>
>> It is not possible. Constants only exist at compile time.
>
>
> yes, but why constant interface values can't exist at compile time?
>  
>

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

Re: [go-nuts] Why can't interface value be constant?

[T L]

On Saturday, August 6, 2016 at 3:58:52 PM UTC+8, Dave Cheney wrote:
>
> It is not possible. Constants only exist at compile time.


yes, but why constant interface values can't exist at compile time?
 

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

Re: [go-nuts] Why can't interface value be constant?

[T L]

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

[go-nuts] Re: IDE for GOLANG

[Simon Ritchie]

Having read the question yet again, I think my answer is as wrong as the 
others.  Sorry about that.

He's already decided to use the Revel framework to build his web service.  
What he appears to want is a piece of software that will create the web 
service for him.

Is that correct, Kritika?



On Saturday, August 6, 2016 at 9:51:56 AM UTC+1, Simon Ritchie wrote:
>
>
> Actually, I think the word IDE in the question is a red herring.  Kritka 
> is asking how to create web services that follow the MVC model.  All of the 
> answers are about somebody's favourite IDE.
>
> Kritika:  if you search Google for "golang web service mvc framework" you 
> will find information about MVC frameworks.  As usual, you can find any 
> information you want on Google, but only if you know the right words - you 
> want a framework, not an IDE.
>
> For what it's worth (which is not much) I've heard good things about 
> Gorilla.
>
> Once you have chosen your framework, you might want to use an IDE to 
> organise and edit your source code.  You don't have to, you can use just a 
> text editor and a terminal to type commands.  Like one of the other people 
> who have posted comments, I'm currently using liteide, but I would disagree 
> with the comment that it's the best.  More like adequate and the least 
> worst that I've found so far.
>
>
> On Tuesday, August 2, 2016 at 1:25:21 PM UTC+1, kritika...@indiamart.com 
> wrote:
>>
>> Hi, 
>> is there IDE for creating a web service in GOLANG by using Revel 
>> framework  which follows MVC architecture.
>>
>> i am using Ubuntu ..
>>
>>
>>
>> *Watch our latest TV Commercial #IndiaKiKhoj 
>> *
>>
>

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

[go-nuts] Re: IDE for GOLANG

[Simon Ritchie]

Actually, I think the word IDE in the question is a red herring.  Kritka is 
asking how to create web services that follow the MVC model.  All of the 
answers are about somebody's favourite IDE.

Kritika:  if you search Google for "golang web service mvc framework" you 
will find information about MVC frameworks.  As usual, you can find any 
information you want on Google, but only if you know the right words - you 
want a framework, not an IDE.

For what it's worth (which is not much) I've heard good things about 
Gorilla.

Once you have chosen your framework, you might want to use an IDE to 
organise and edit your source code.  You don't have to, you can use just a 
text editor and a terminal to type commands.  Like one of the other people 
who have posted comments, I'm currently using liteide, but I would disagree 
with the comment that it's the best.  More like adequate and the least 
worst that I've found so far.


On Tuesday, August 2, 2016 at 1:25:21 PM UTC+1, kritika...@indiamart.com 
wrote:
>
> Hi, 
> is there IDE for creating a web service in GOLANG by using Revel framework 
>  which follows MVC architecture.
>
> i am using Ubuntu ..
>
>
>
> *Watch our latest TV Commercial #IndiaKiKhoj 
> *
>

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

Re: [go-nuts] Why can't interface value be constant?

[T L]

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

no, the value an interface wraps can't be addressed.

const bool/number/string interfaces make it is possible the exported error 
variables in standard lib become constant.
 

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

[go-nuts] Re: Go package management proposal process

[Peter Bourgon]

To be clear, there is no self-nomination or seconding/voting process
in place at this time. Thanks for bearing with me as I iron out the
final details of the process.

On Sat, Aug 6, 2016 at 7:16 AM, James Pirruccello
 wrote:
> I'd be happy to second your nomination.
>
>
> On Saturday, August 6, 2016 at 12:58:48 AM UTC-4, Dave Cheney wrote:
>>
>> Hello,
>>
>> I wish to nominate myself to be part of the working group. I have written
>> up my position statement here:
>>
>> https://gist.github.com/davecheney/48c07d20f8cf38cce61c940d7bd55644
>>
>> I am seeking a second for my nomination.
>>
>> Thank you
>>
>> Dave
>>
>> On Friday, 29 July 2016 17:46:01 UTC+10, Peter Bourgon wrote:
>>>
>>> Hello,
>>>
>>> For well over a year, a group of dedicated Gophers have been
>>> discussing the package management situation on a dedicated mailing
>>> list, in Slack #vendor, and several communication channels. A few
>>> tools have emerged from those broad conversations, including Glide,
>>> govendor, gb, and the SAT solver gps. And at GopherCon 2016, a panel
>>> with several members of the core Go team was held.
>>>
>>> While much remains to be decided, a few things are clear. The package
>>> management solution, whatever it will be, will take the form of one or
>>> more official Go language proposals. And the proposals (and their
>>> eventual implementation) will be driven by a small committee of
>>> dedicated Gophers.
>>>
>>> In the interest of progress, I've volunteered to shepherd this process
>>> from start to finish. I've created a document detailing a proposal for
>>> the process itself. If this topic interests you, please review and
>>> comment.
>>>
>>>
>>> https://docs.google.com/document/d/18tNd8r5DV0yluCR7tPvkMTsWD_lYcRO7NhpNSDymRr8
>>>
>>> As much as anything can be official, I hope that this will be the
>>> official process, leading to the long-desired blessed solution.
>>>
>>> Regards,
>>> Peter Bourgon.

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

Re: [go-nuts] Why can't interface value be constant?

[atd...@gmail.com]

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



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

Re: [go-nuts] Why can't interface value be constant?

[Dave Cheney]

It is not possible. Constants only exist at compile time.

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

Re: [go-nuts] Why can't interface value be constant?

[T L]

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