I agree with Nate. The consistency in typing is a very compelling argument.
On Mon, Oct 24, 2016, 22: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.
>
> 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.
