Re: [go-nuts] allow {3}, {true} etc

On 24 October 2016 at 21:14, Nate Finch wrote: > Because it's consistent with how you get a pointer for other types... if I'm > used to using {x} for structs, maps, and slices, then it's perfectly > natural to try that with builtins and arrays. If someone says "oh, sorry, >

Re: [go-nuts] allow {3}, {true} etc

I agree with Nate. The consistency in typing is a very compelling argument. On Mon, Oct 24, 2016, 22:14 Nate Finch wrote: > Because it's consistent with how you get a pointer for other types... if > I'm used to using {x} for structs, maps, and slices, then it's perfectly >

Re: [go-nuts] allow {3}, {true} etc

Because it's consistent with how you get a pointer for other types... if I'm used to using {x} for structs, maps, and slices, then it's perfectly natural to try that with builtins and arrays. If someone says "oh, sorry, for ints you have to use ref(5)" then I'm going to get annoyed at an

Re: [go-nuts] allow {3}, {true} etc

How would new syntax be better than a built-in function with exactly the semantics you are after and shorter to type to boot? On 23 Oct 2016 01:50, "Nate Finch" wrote: > I'd much rather have syntax that just works rather than another built-in > function. > > On Sat, Oct

Re: [go-nuts] allow {3}, {true} etc

I'd much rather have syntax that just works rather than another built-in function. On Sat, Oct 22, 2016, 6:17 PM roger peppe wrote: > When I need to do this, I find it's only a very minor annoyance to define: > > func newInt(i int) { return } > > If Go ever got

Re: [go-nuts] allow {3}, {true} etc

When I need to do this, I find it's only a very minor annoyance to define: func newInt(i int) { return } If Go ever got generics, this would probably be trivial to write generically, for example: func Ref[T](x T) *T { return } I don't think I'd object if we added a new builtin

Re: [go-nuts] allow {3}, {true} etc

I agree that a spoonful of syntactic sugar would be wonderful here, though I don't have any strong opinions on what form it should take. On Saturday, October 22, 2016 at 12:31:58 PM UTC-6, Pietro Gagliardi (andlabs) wrote: > > > On Oct 22, 2016, at 2:19 PM, Matt Harden >

Re: [go-nuts] allow {3}, {true} etc

> On Oct 22, 2016, at 2:19 PM, Matt Harden wrote: > > and [...]int{5}[:] is also illegal (slice of unaddressable value) []int{5} will do the same thing, and I didn't know this until recently but the spec is written such that this even works with named indices:

Re: [go-nuts] allow {3}, {true} etc

Interesting - &[]int{5}[0] works, but &[...]int{5}[0] doesn't, and [...]int{5}[:] is also illegal (slice of unaddressable value). I guess I always thought of []T{x,y,z} as sugar for [...]T{x,y,z}[:] but it's more like func()[]T{a := [...]T{x,y,z}; return a[:]}() I agree these are horrible. I just

Re: [go-nuts] allow {3}, {true} etc

Which is effectively the same as my proposal, except horrible. On Sat, Oct 22, 2016, 12:18 PM Ian Lance Taylor wrote: > > You can, of course, write > p3 := &({5}).i > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts"

Re: [go-nuts] allow {3}, {true} etc

On Sat, Oct 22, 2016 at 8:42 AM, Matt Harden wrote: > I don't like the syntax {0} because int is not a compound type, but > (0) seems reasonable syntax to me. I do think there is an irregularity > in the language here: > > type Int struct{i int} > anInt := Int{5} > p1 :=

Re: [go-nuts] allow {3}, {true} etc

Perhaps regular was the wrong choice of phrasing. From an end-user's perspective, it makes the language more consistent, rather than having {v} work for some of the more complex values of T, but not for the more simple values of T. On Fri, Oct 21, 2016 at 3:59 PM Jan Mercl <0xj...@gmail.com>

Re: [go-nuts] allow {3}, {true} etc

On Fri, Oct 21, 2016 at 9:20 PM Nate Finch wrote: > And, I would argue, it actually makes the language slightly more regular, since now {v} works for just about everything (possibly everything?). Taking the address of an addressable thing is the regular proper. Taking

Re: [go-nuts] allow {3}, {true} etc

That's fair. But I think it's a worthwhile (and fairly minor) complexity to add to the spec to make the language a lot easier to use in some very common use cases. And, I would argue, it actually makes the language slightly more regular, since now {v} works for just about everything

Re: [go-nuts] allow {3}, {true} etc

On Fri, Oct 21, 2016 at 11:39 AM, Nate Finch wrote: > I don't think it's ambiguous at all. We already do different things for > different T in T{v}. For slices, the slice is constructed and then each > value is an item in the slice. For structs, the struct is constructed

Re: [go-nuts] allow {3}, {true} etc

I don't think it's ambiguous at all. We already do different things for different T in T{v}. For slices, the slice is constructed and then each value is an item in the slice. For structs, the struct is constructed and then the fields are filled out in declaration order. We're just adding

Re: [go-nuts] allow {3}, {true} etc

On Fri, Oct 21, 2016 at 9:49 AM, Nate Finch wrote: > > I'd really like to see the composite literal syntax extended to work with > non-composite types, so you could do something like this: > > f := Foo{ Count: {5} } That doesn't work as is, because &[]interface{nil} is

Re: [go-nuts] allow {3}, {true} etc

I would also like an easier way to construct pointers to ints/bools/strings. Note that there is a way to write convoluted code that makes e.g. {3} legal: https://play.golang.org/p/leP5_12IX0 AFAICT this isn't a backwards-compatibility concern, though. Like you, I would really like &5 to work but

Re: [go-nuts] allow {3}, {true} etc

I had missed that, thanks. The one response does not really fit the problem, though. There are a lot of times when POS (plain old structs) make a really nice UX (or would, if they weren't a pain to handle). I like option types like Dave said, but that's really a whole different beast that

Re: [go-nuts] allow {3}, {true} etc

On Fri, 21 Oct 2016 09:49:24 -0700 (PDT) Nate Finch wrote: > One of the problems with working with serialization of any kind is > dealing with unset vs the zero value. The usual way to get around > this is to use a pointer, nil is unset, non-nil is set. But this > gets

[go-nuts] allow {3}, {true} etc

One of the problems with working with serialization of any kind is dealing with unset vs the zero value. The usual way to get around this is to use a pointer, nil is unset, non-nil is set. But this gets annoying when trying to make literal values, because you can't take the address of a