spec: suggest improve new function and add &T(x) grammar

[chai2010]

1. improve new func (by Albert Liu @ jpush)

func new(Type, value ...Type) *Type

2. support &Type(value) grammar

Examples:

px := new(int, 9527)

px := &int(9527)

Some discuss about `make` and `new`:

https://groups.google.com/d/msg/golang-nuts/kWXYU95XN04/iB2ZX0ixcHcJ

https://groups.google.com/d/msg/golang-nuts/04KxpugfNvQ/dMiR9dxzcLsJ

https://groups.google.com/d/msg/golang-nuts/kWXYU95XN04/iRfB7YEt57UJ

--

https://github.com/chai2010

[Volker Dobler]

Am Dienstag, 11. November 2014 10:15:47 UTC+1 schrieb chai2010:

1. improve new func (by Albert Liu @ jpush)

func new(Type, value ...Type) *Type

2. support &Type(value) grammar

Examples:

px := new(int, 9527)

px := &int(9527)

Which real-world problems does this solve? What is wrong with the

existing way to get the pointer to an int value with a specific value?

V. 

[chai2010]

Like `proto.Int32` in goprotobuf (http://godoc.org/code.google.com/p/goprotobuf/proto#Int32):

pb.X = proto.Int32(9527)

We can write the simple code:

pb.X = new(int32, 9527)

pb.X = &int32(9527)

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

https://github.com/chai2010

[Volker Dobler]

Am Dienstag, 11. November 2014 10:41:48 UTC+1 schrieb chai2010:

Like `proto.Int32` in goprotobuf (http://godoc.org/code.google.com/p/goprotobuf/proto#Int32):

pb.X = proto.Int32(9527)

We can write the simple code:

pb.X = new(int32, 9527)

pb.X = &int32(9527)

I neither think that protobuf code is a good example nor that the

"simple code" is convincingly simpler or better.

V

[roger peppe]

When I find I need something like your new(int, 9527), I just
define a function:

func newInt(i int) *int { return &i }

Lack of this feature has never seemed like a major stumbling
block to me.

[chai2010]

Do you really think these codes are simple?

// https://code.google.com/p/goprotobuf/source/browse/proto/lib.go#280

/*

* Helper routines for simplifying the creation of optional fields of basic type.

*/

// Bool is a helper routine that allocates a new bool value

// to store v and returns a pointer to it.

func Bool(v bool) *bool {

return &v

}

// Int32 is a helper routine that allocates a new int32 value

// to store v and returns a pointer to it.

func Int32(v int32) *int32 {

return &v

}

// Int is a helper routine that allocates a new int32 value

// to store v and returns a pointer to it, but unlike Int32

// its argument value is an int.

func Int(v int) *int32 {

p := new(int32)

*p = int32(v)

return p

}

// Int64 is a helper routine that allocates a new int64 value

// to store v and returns a pointer to it.

func Int64(v int64) *int64 {

return &v

}

// Float32 is a helper routine that allocates a new float32 value

// to store v and returns a pointer to it.

func Float32(v float32) *float32 {

return &v

}

// Float64 is a helper routine that allocates a new float64 value

// to store v and returns a pointer to it.

func Float64(v float64) *float64 {

return &v

}

// Uint32 is a helper routine that allocates a new uint32 value

// to store v and returns a pointer to it.

func Uint32(v uint32) *uint32 {

p := new(uint32)

*p = v

return p

}

// Uint64 is a helper routine that allocates a new uint64 value

// to store v and returns a pointer to it.

func Uint64(v uint64) *uint64 {

return &v

}

// String is a helper routine that allocates a new string value

// to store v and returns a pointer to it.

func String(v string) *string {

return &v

}

If `new` func is really powerful, the goprotobud donot need these helper func.

[chai2010]

Yes, lack of this feature never block me.

Just like lack of `for-range` feature never block me.

So, wo donot need `for-range` feature...

http://tip.golang.org/doc/go1.4#forrange

--

https://github.com/chai2010

[chai2010]

And many protobuf users just need these helper funcs,

they must import the `proto` packages.

Like this code (https://github.com/chai2010/protorpc/blob/master/internal/service.pb/echo.go):

package service

import (

"github.com/chai2010/protorpc/proto"

)

type Echo int

func (t *Echo) Echo(args *EchoRequest, reply *EchoResponse) error {

reply.Msg = proto.String(args.GetMsg())

return nil

}

func (t *Echo) EchoTwice(args *EchoRequest, reply *EchoResponse) error {

reply.Msg = proto.String(args.GetMsg() + args.GetMsg())

return nil

}

This package import the `proto` package, only for `proto.String` helper func.

--

https://github.com/chai2010

[Andrew Gerrand]

Protocol buffers were designed before Go was designed. If they were designed for Go, there would be no optional fields, proto structs would not use pointer values, and these helpers would be unnecessary.

The (poor) design of Protocol Buffers should not be a consideration when making Go language design decisions.

Andrew

--
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...@googlegroups.com.

[chai2010]

From standard pacakge:

http://golang.org/src/pkg/encoding/asn1/asn1_test.go?#L350

func newInt(n int) *int { return &n }

func newInt64(n int64) *int64 { return &n }

func newString(s string) *string { return &s }

func newBool(b bool) *bool { return &b }

http://golang.org/src/pkg/text/template/exec_test.go?#L146

// Helpers for creation.

func newInt(n int) *int {

return &n

}

func newString(s string) *string {

return &s

}

func newIntSlice(n ...int) *[]int {

p := new([]int)

*p = make([]int, len(n))

copy(*p, n)

return p

}

--

https://github.com/chai2010

[Andrew Gerrand]

I agree that the proposed feature is useful and that there are real uses for it, I just don't see that it's worth the complexity.

[chai2010]

Thanks for your approval.

I create a new issue about this:

https://code.google.com/p/go/issues/detail?id=9097

--

https://github.com/chai2010

[Tahir]

Unless I am mistaken, the case for "px := &int(9527)" might be a little problematic. int(9527) has no address.

[chai2010]

2014-11-13 15:40 GMT+08:00 Tahir <welcometot...@gmail.com>:

Unless I am mistaken, the case for "px := &int(9527)" might be a little problematic. int(9527) has no address.

 

`px := &int(9527)` is same as:

temp := int(9527)

px := &temp 

--

https://github.com/chai2010

[Tahir]

That's a good idea but doesn't that mean that type conversion will have to change so that it allocates (since int(*) is used for that too) ?

[Andrew Gerrand]

I wasn't giving my approval. All features are useful. (No sensible person would sincerely suggest a feature they thought was useless.)

But we shouldn't judge features by their utility, but rather by the tradeoffs you have to make to include them. This feature adds a lot of complexity, but doesn't help in many cases. As someone who teaches Go, I wouldn't want to have to explain this feature. I kind of wish we could get rid of 'new' entirely.

[Sean Russell]

On Thursday, November 13, 2014 5:51:25 AM UTC-5, Andrew Gerrand wrote:

I kind of wish we could get rid of 'new' entirely

This.

--- SER

[Brendan Tracey]

There is no need for the int slice version. This already exists http://play.golang.org/p/ZG89-WRZGc

[chai2010]

2014-11-14 0:31 GMT+08:00 Chris Manghane <cm...@golang.org>:

On Wed, Nov 12, 2014 at 11:47 PM, chai2010 <chais...@gmail.com> wrote:

2014-11-13 15:40 GMT+08:00 Tahir <welcometot...@gmail.com>:

Unless I am mistaken, the case for "px := &int(9527)" might be a little problematic. int(9527) has no address.

 

`px := &int(9527)` is same as:

temp := int(9527)

px := &temp 

I might be missing the point, but why not just write this if this is what you want?

Right now the spec says "The operand must be addressable, that is, either a variable, pointer indirection, or slice indexing operation; or a field selector of an addressable struct operand; or an array indexing operation of an addressable array" (http://golang.org/ref/spec#Address_operators). That seems like a reasonable requirement but with this change, suddenly `int(9527)` would need to be addressable. Does that also mean the untyped constant `9527` is addresssable, as well, and if not, why not? How does addressability fit into this suggestion?

I just expect a simple way to new and set `int` value, like these:

_ = &[]int{}

_ = &[1]int{}

_ = &map[string]int{}

_ = &StructType{}

_ = &int(0) // error: cannot take the address

_ = &int{0} // error: invalid pointer type *int for composite literal 

--

https://github.com/chai2010

[Dave Cheney]

Chai,

Andrew has said very clearly

> The (poor) design of Protocol Buffers should not be a consideration when making Go language design decisions.

I appreciate that the design of protobufs requires some odd syntax that isn't very idiomatic or convenient, but the solution to this is to write a set of helper functions. 

This is not an infinite set of helpers, and once it's done, you don't need to:

a. wait for a version of Go that will probably never support this feature

b. have to compromise the design of this feature with someone else which may result in what you want being added, but in a way that isn't 100% suitable for your use.

Dave

[mikespook]

Here's a proposal witch should be related with this topic.

I'd like you to review and make some comments.

https://docs.google.com/document/d/111YaXFZeJbJ9DhOF69CvvFV49YTkUKpIRKiS42woMak/edit?usp=sharing

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Xing Xing (邢星)
mikespook <mike...@gmail.com>
http://mikespook.com

[Dave Cheney]

If you are asking me [1] to review this proposal, then my response is
your proposal requires, above all else, a compelling motivation. This
proposal does not have such motivation.

Several commenters, including myself have said that adding a language
feature to support protobufs is not sufficient motivation, and a
suitable workaround exists, for inclusion in Go 1. The Go designers
have indicated this by marking the issue you raised as Go 2.

Please respect this very clear message.

Dave

1. Probably for the best, I am not a Go designer, just an enthusiastic
contributor.