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