Why not have a github emoji vote.

1. () `type MyMap(K comparable, V something) struct { m map[k]v }; fn(int,
float)(4, .20);`
2. [] `type MyMap[K comparable, V something] struct { m map[k]v }; fn[int,
float](4, .20);`
3. <::> `type MyMap<:K comparable, V something:> struct { m map[k]v };
fn<:int,float:>(4, .20);`
4. ::<> `type MyMap::<K comparable, V something> struct { m map[k]v };
fn::<int,float>(4, .20);`
5..8 ... other viable suggestions

That way the community would be able to easily vote and give the developers
a better idea,
because a lot of people don't even use the mailing list.




On Thu, Jul 16, 2020 at 2:51 PM Ian Lance Taylor <i...@golang.org> wrote:

> On Thu, Jul 16, 2020 at 12:41 PM joshua harr <joshua.h...@gmail.com>
> wrote:
> >
> > Just a note on your rationale for why not to use <: :> :
> > "... requires more typing." Golang has, rather famously, never shied
> away from making developers type more. The reason it hasn't, as far as I
> understand, is that code is read far often than it is written, and so the
> extra verbosity is worth the ease in reading the code. IMHO, that principle
> very much applies here. The *readability* of the syntax should be a far
> more important consideration than whether there is an extra character in
> the syntax.
>
> That's a fair point.  Having two characters is still in my mind a
> disadvantage, but I agree that that disadvantage could be outweighed
> by a gain in readability.
>
> That said, personally I don't find <:T:> to be any more (or less)
> readable than [T].
>
> Ian
>
>
>
> > On Wednesday, July 15, 2020 at 12:14:31 AM UTC-4 Ian Lance Taylor wrote:
> >>
> >> On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W. <oneo...@gmail.com>
> wrote:
> >> >
> >> > This feels a little better, but honestly I'm still all for angle
> brackets or like Watson suggested, guillamets.
> >> >
> >> > fn(T1)(fn2(T2)(fn3(T3)(v))) // 1
> >> > fn[T1](fn2[T2](fn3[T3](v))) // 2
> >> > fn<T1>(fn2<T2>(fn3<T3>(v))) // 3
> >> > fn«T1»(fn2«T2»(fn3«T3»v))) // 4
> >> >
> >> > To me, with a background in C++ and Typescript and a little bit of
> Rust, #3 and #4 are just natural and easier to read.
> >>
> >> The advantage of parentheses is that the language already uses
> >> parentheses for lists in various places. Of course that is also the
> >> disadvantage.
> >>
> >> When considering something other than parentheses, I encourage people
> >> to look for objective reasons why one syntax is better than another.
> >> It's going to be different from other aspects of the language. So
> >> what reason would we have for preferring one syntax over another?
> >>
> >> For example:
> >>
> >> Robert already gave reasons why square brackets are better than angle
> brackets.
> >>
> >> The disadvantage of guillemets is that they are hard to type on many
> >> keyboards. So to me either square brackets or angle brackets would be
> >> better than guillemets.
> >>
> >> The disadvantage of a two character sequence such as <: :> is that it
> >> is more typing. So again either square brackets or angle brackets
> >> seem to me to be better.
> >>
> >> An example of a reason that square brackets might be a poor choice
> >> would be ambiguous parsing, or cases where the code is harder to read.
> >>
> >> It's true that some other languages use angle brackets, but Go already
> >> does many things differently. That is only a minor advantage for
> >> angle brackets. To me at least it does not outweigh the
> >> disadvantages.
> >>
> >> In short, please try to provide reasons for a different syntax. "It
> >> looks good" is a valid reason, but please try to explain why it looks
> >> better than square brackets or parentheses.
> >>
> >> Thanks.
> >>
> >> Ian
> >
> > --
> > 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.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/985c8685-484c-417c-a421-fe7a222d56c7n%40googlegroups.com
> .
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/7t-Q2vt60J8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUu0Jh%3DCsQ-0zy%3DkY3uFesYPBUAovYbvUyvPxpW%2BpPEiw%40mail.gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANi8n3D_jY9Jm5Et9mzFgOoMLQHP3ZaLoTi85r%3DpG80-zaffXQ%40mail.gmail.com.

Reply via email to