On Wed, 15 Jul 2020 14:51:17 -0700
jimmy frasche <soapboxcic...@gmail.com> wrote:
> I didn't care about () except for having to then have extra parens
> around types in a lot of places which was very annoying and came up
> often. If [] fixes that, great!
I was pretty unhappy with () just because there's too many () and it's
hard to tell them apart by eyeball. Even if the parsing isn't strictly
ambiguous, it's annoying to try to decipher; I already feel like too
many things use ()s.
That said, if people don't like square brackets, I'm totally prepared
to make worse suggestions until they give up and say square brackets
aren't that bad.
old proposal:
func F(type T) (x T) (T, error)
new proposal:
func F[type T] (x T) (T, error)
:seebsno:
func F/type T/(x T) (T, error)
Or we could do sed-style "any character can be the delimiter if
you use it where we expect a delimiter", except using "right before
the type keyword", so for instance:
func F!type T!(x T) (T, error)
func Fxtype Tx(x T) (T, error) // yes you can use x
And we could also support regex-style flags on these to resolve
the "how should the compiler actually implement this", by letting you
specify implementation-choice flags:
func F/type T/g(x T) (T, error) // generate specialized code
func F/type T/i(x T) (T, error) // inline
func F/type T/p(x T) (T, error) // print lines to output??!
func F/type T/q(x T) (T, error) // exit compilation early
Not bad enough? No problem! We'll just... use XML. That should help us
win over the enterprise market, right?
<generic implementation="generated,refected">
<type T constraints="<![CDATA[Stringer]]>">
func F(x T) (T, error)
</type>
</generic>
(The indentation is mandatory, of course, with two spaces before the
<type> tags, and a tab with no leading spaces before the code inside
them.)
If it weren't for the parser things, I'd prefer <> to []. However, I am
also fine with [type T]; it's clear and unambiguous, and gets away from
the "everything goes in ()s" that was my only real complaint about the
proposal.
(And yes I thought of the "unicode characters that happen to look like
angle brackets" idea, but someone already implemented it that way, so
it's not novel.)
-s
--
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/20200715171009.535f35a9%40seebsdell.
