> On Jul 15, 2020, at 1:49 PM, Ian Lance Taylor <i...@golang.org> wrote:
>
> On Tue, Jul 14, 2020 at 11:06 PM Bakul Shah <ba...@iitbombay.org> wrote:
>>
>> I don't much like square brackets or angle brackets or guillemets. But here
>> is a different way
>> of reducing the need for parentheses at least for the common case:
>>
>> A proposal for fewer irritating parentheses!
>>
>> One thing to note is that generic functions & types are *different* from
>> existing things like const, func, type, var. As such they should have their
>> own declaration marker. For example
>>
>> gen T type pair struct { a, b T } // contrast with type pair(type T) ...
>> gen T,U type W struct { a T; b U } // contrast with type W(type T, U) ...
>> gen T func Print(s []T) {...} // print a slice of T
>>
>> These function/type/method generics are used by *prepending* the type:
>>
>> var x int pair // a pair of ints
>> var y (int, int pair) W // here we have to use parentheses
>> int Print([]int{1,2,3}) // print a slice of ints
>> qq := int pair pair{{1,2},{3,4}} // a pair of a pair of ints
>> ww := (int, int) W pair{{1,2},{3,4}}
>>
>> This use may seem weird if you are used to C/C++. I find it more readable
>> than having to deal with extra parentheses. "int pair" clearly says a
>> pair of ints and so on. What is more, if in future types are allowed to be
>> *inferred* for generic function calls, you can simply drop the type prefix.
>>
>> If there is still a parsing ambiguity, I'd suggest adding a - as in int-pair.
>>
>> Additional type syntax rule:
>>
>> type: ... | type generic-type| (type-list) generic-type
>>
>> or
>>
>> type: ... | type "-" generic-type | (type-list) "-" generic-type
>>
>> FWIW I thought of this four weeks ago (June 16).
>
>
> Thanks for the note. It's an interesting idea, but I'm not quite sure
> it works to have prefix types with no real delimiters. It may work to
> write "int pair pair" but does it work to write "func() int pair
> pair"? That is the type of a pair of functions where each function
> returns the type "int pair". If we have to start carefully deciding
> where we need to add parentheses then I'm not sure we've gained very
> much by switching to this kind of syntax.
The syntax rule I envisioned was this:
type: ... | type generic-type | ...
To me, using full parenthesization, this would be
func() int pair pair" == "((func() int) pair)pair --(1)
What you seem to want is
(func() (int pair)) pair --(2)
Contrast that with
pair[pair[func() int]] --(1)
and
pair[func()pair[int]] --(2)
As I see it, the alternate syntax is no worse for extreme cases but much better
for the common case.
The second issue is the usage for generic functions. Contrast
(float64, int)PowN(1.2, 3)
with
PowN[float64, int](1.2, 3)
or currently
PowN(float64, int)(1.2, 3)
I find the alternate syntax easier because conceptually the concrete types
used to select a specific concrete function is a different activity than
passing arguments to a function at runtime so IMHO they should be visually
different. It is almost like C style cast. Think of it as casting a generic
function (or type) to a concrete function or type!
--
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/65AF00C2-1CAE-4876-84A8-8BADD4A740CE%40iitbombay.org.
