FAQ

Search Discussions

  • Andrew Gerrand at Nov 12, 2014 at 1:47 am
  • Chai2010 at Nov 12, 2014 at 1:59 am
  • Andrew Gerrand at Nov 12, 2014 at 2:13 am
  • Chai2010 at Nov 13, 2014 at 7:20 am
    Thanks for your approval.

    I create a new issue about this:
    https://code.google.com/p/go/issues/detail?id=9097

    2014-11-12 10:13 GMT+08:00 Andrew Gerrand <adg@golang.org>:
    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.

    On Wed Nov 12 2014 at 12:59:23 PM chai2010 wrote:

    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
    }


    2014-11-12 9:47 GMT+08:00 Andrew Gerrand <adg@golang.org>:
    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

    On Wed Nov 12 2014 at 12:27:22 PM chai2010 <chaishushan@gmail.com>
    wrote:
    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.

    2014-11-11 17:15 GMT+08:00 chai2010 <chaishushan@gmail.com>:
    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

    --
    https://github.com/chai2010

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

    --
    https://github.com/chai2010

    --
    https://github.com/chai2010

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Tahir at Nov 13, 2014 at 7:40 am
    Unless I am mistaken, the case for "px := &int(9527)" might be a little
    problematic. int(9527) has no address.
    On Thursday, November 13, 2014 7:20:17 AM UTC, chai2010 wrote:

    Thanks for your approval.

    I create a new issue about this:
    https://code.google.com/p/go/issues/detail?id=9097

    2014-11-12 10:13 GMT+08:00 Andrew Gerrand <a...@golang.org <javascript:>>:
    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.


    On Wed Nov 12 2014 at 12:59:23 PM chai2010 <chais...@gmail.com
    <javascript:>> wrote:
    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
    }


    2014-11-12 9:47 GMT+08:00 Andrew Gerrand <a...@golang.org <javascript:>>
    :
    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

    On Wed Nov 12 2014 at 12:27:22 PM chai2010 <chais...@gmail.com
    <javascript:>> wrote:
    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.

    2014-11-11 17:15 GMT+08:00 chai2010 <chais...@gmail.com <javascript:>>
    :
    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

    --
    https://github.com/chai2010

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

    --
    https://github.com/chai2010

    --
    https://github.com/chai2010
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Chai2010 at Nov 13, 2014 at 7:49 am

    2014-11-13 15:40 GMT+08:00 Tahir <welcometothebasement@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
    On Thursday, November 13, 2014 7:20:17 AM UTC, chai2010 wrote:

    Thanks for your approval.

    I create a new issue about this:
    https://code.google.com/p/go/issues/detail?id=9097

    2014-11-12 10:13 GMT+08:00 Andrew Gerrand <a...@golang.org>:
    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.

    On Wed Nov 12 2014 at 12:59:23 PM chai2010 wrote:

    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
    }


    2014-11-12 9:47 GMT+08:00 Andrew Gerrand <a...@golang.org>:
    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
    On Wed Nov 12 2014 at 12:27:22 PM chai2010 wrote:

    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.

    2014-11-11 17:15 GMT+08:00 chai2010 <chais...@gmail.com>:
    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

    --
    https://github.com/chai2010

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

    --
    https://github.com/chai2010

    --
    https://github.com/chai2010

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


    --
    https://github.com/chai2010

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Tahir at Nov 13, 2014 at 8:03 am
    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) ?

    On Thursday, November 13, 2014 7:49:54 AM UTC, chai2010 wrote:



    2014-11-13 15:40 GMT+08:00 Tahir <welcometot...@gmail.com <javascript:>>:
    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
    On Thursday, November 13, 2014 7:20:17 AM UTC, chai2010 wrote:

    Thanks for your approval.

    I create a new issue about this:
    https://code.google.com/p/go/issues/detail?id=9097

    2014-11-12 10:13 GMT+08:00 Andrew Gerrand <a...@golang.org>:
    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.

    On Wed Nov 12 2014 at 12:59:23 PM chai2010 wrote:

    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
    }


    2014-11-12 9:47 GMT+08:00 Andrew Gerrand <a...@golang.org>:
    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

    On Wed Nov 12 2014 at 12:27:22 PM chai2010 <chais...@gmail.com>
    wrote:
    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.

    2014-11-11 17:15 GMT+08:00 chai2010 <chais...@gmail.com>:
    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

    --
    https://github.com/chai2010

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

    --
    https://github.com/chai2010

    --
    https://github.com/chai2010

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


    --
    https://github.com/chai2010
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Chai2010 at Nov 14, 2014 at 1:21 am
    2014-11-14 0:31 GMT+08:00 Chris Manghane <cmang@golang.org>:
    On Wed, Nov 12, 2014 at 11:47 PM, chai2010 wrote:



    2014-11-13 15:40 GMT+08:00 Tahir <welcometothebasement@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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Nov 14, 2014 at 2:22 am
    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
    On Friday, 14 November 2014 12:21:40 UTC+11, chai2010 wrote:



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

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

    2014-11-13 15:40 GMT+08:00 Tahir <welcometot...@gmail.com <javascript:>>
    :
    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
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Mikespook at Nov 14, 2014 at 6:08 am
    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

    2014-11-14 10:22 GMT+08:00 Dave Cheney <dave@cheney.net>:
    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
    On Friday, 14 November 2014 12:21:40 UTC+11, chai2010 wrote:



    2014-11-14 0:31 GMT+08:00 Chris Manghane <cm...@golang.org>:
    On Wed, Nov 12, 2014 at 11:47 PM, chai2010 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

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


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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Nov 14, 2014 at 6:30 am
    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.
    On Fri, Nov 14, 2014 at 5:08 PM, mikespook wrote:
    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

    2014-11-14 10:22 GMT+08:00 Dave Cheney <dave@cheney.net>:
    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
    On Friday, 14 November 2014 12:21:40 UTC+11, chai2010 wrote:



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

    On Wed, Nov 12, 2014 at 11:47 PM, chai2010 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
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.



    --
    Xing Xing (邢星)
    mikespook <mikespook@gmail.com>
    http://mikespook.com
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Andrew Gerrand at Nov 13, 2014 at 10:50 am
    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.
    On Thu Nov 13 2014 at 6:20:04 PM chai2010 wrote:

    Thanks for your approval.

    I create a new issue about this:
    https://code.google.com/p/go/issues/detail?id=9097

    2014-11-12 10:13 GMT+08:00 Andrew Gerrand <adg@golang.org>:
    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.

    On Wed Nov 12 2014 at 12:59:23 PM chai2010 wrote:

    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
    }


    2014-11-12 9:47 GMT+08:00 Andrew Gerrand <adg@golang.org>:
    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

    On Wed Nov 12 2014 at 12:27:22 PM chai2010 <chaishushan@gmail.com>
    wrote:
    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.

    2014-11-11 17:15 GMT+08:00 chai2010 <chaishushan@gmail.com>:
    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

    --
    https://github.com/chai2010

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

    --
    https://github.com/chai2010

    --
    https://github.com/chai2010
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Sean Russell at Nov 13, 2014 at 11:35 am

    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

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Brendan Tracey at Nov 13, 2014 at 3:35 pm
    There is no need for the int slice version. This already exists
    http://play.golang.org/p/ZG89-WRZGc

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 12, '14 at 1:27a
activeNov 14, '14 at 6:30a
posts15
users7
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase