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