On 24 October 2016 at 21:14, Nate Finch <nate.fi...@gmail.com> wrote:
> Because it's consistent with how you get a pointer for other types... if I'm
> used to using &T{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
> inconsistency that seems to exist for no reason.
>
> It's also less likely to overlap with existing code. A function called ref
> could very well already exist in a current codebase. But there's likely
> almost no code that uses builtin type names as anything other than the types
> themselves. And unless you have structs that use builtin type names,
> &int{5} won't currently compile.
It doesn't really matter if a function called ref is defined already,
as it won't be a problem until you actually want to use it.
(FWIW there are no functions named "ref" in the 1640556
lines of Go code in my GOPATH).
To me the T{...} syntax says "structured type literal" - wrapping
an integer in {} and saying that it's a scalar value seems wrong.
I like "ref" because it involves almost no changes to existing
tooling and it's also useful in other case.
For example, I commonly want to make a shallow copy
of an object. Currently I tend to do this:
func x(t *T) {
t1 := *t
y(&t1)
}
but feels a little awkward that t1 is of a different type than T.
func x(t *T) {
t1 := ref(*t)
y(t1)
}
feels a little cleaner.
cheers,
rog.
>
> On Monday, October 24, 2016 at 3:45:29 PM UTC-4, rog wrote:
>>
>> 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" <nate....@gmail.com> wrote:
>>>
>>> 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 <rogp...@gmail.com> wrote:
>>>>
>>>> I don't think I'd object if we added a new builtin function called "ref"
>>>> with the above semantics. It worked pretty well in Limbo as an operator.
>
> --
> 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.
