On Tue, 2020-07-14 at 23:05 -0700, Bakul Shah 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).
> 

How do these deal with non-type determined uses. Say you have (by any
spelling)

gen F,I func PowN(a F, b I) F {...}

How do you specify the type of F or I when say you have untyped
constants. This still requires parens or other markings to indicate the
actual types of F and I. It seems many of the comments here complaining
about brackets and such are ignoring this aspect of the current
proposal.


-- 
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/f71c554665750d8dcc3a8d3dd69ec7e2f996b896.camel%40kortschak.io.

Reply via email to