[generics] Separating type parameters, regular parameters, and return parameters

[wher...@gmail.com]

Hello,

Consider the code below (taken from the Design Draft and slightly modified):

func ConcatTo[S Stringer, P Plusser](s []S, p []P) (r []string) {

  r = make([]string, len(s))

  for i, v := range s {

    r[i] = p[i].Plus(v.String())

  }

  return r

}

It becomes immediately obvious that the set of parameters become slightly hard to read and could require a lot of editor help (via highlight, most likely) to distinguish between them. I'd like to propose that we separate the type and function parameters from the return parameters with a colon, so that the above code will become:

func ConcatTo[S Stringer, P Plusser](s []S, p []P): (r []string) {

  r = make([]string, len(s))

  for i, v := range s {

    r[i] = p[i].Plus(v.String())

  }

  return r

}

With the colon, the parameters are easy to scan and don't require careful attention in order to make out the parts. More importantly, while the editor highlighting will be a good thing (and could greatly benefit from the presence of the colon), it doesn't become strictly necessary.

Regards,

Yaw

[Axel Wagner]

On Fri, Nov 27, 2020 at 3:14 PM wher...@gmail.com <wher...@gmail.com> wrote:

I'd like to propose that we separate the type and function parameters from the return parameters with a colon

That would mean that either a) generic and non-generic functions would differ by a : after the arguments, which seems confusing, or b) we could allow non-generic functions to also have a :, but then we'd have two ways to write them, which also seems confusing or c) we could require them to have a :, which would break compatibility.

Personally, I don't like either of them. And perceive any readability benefit to be very minor at best. I don't really see them as significantly different at all.

I also feel that we already changed from `()` to `[]` and removed the `type`, to help readability. I think at some point we're just going to have to accept that generic function signatures are inherently more crowded and less readable and stop hoping that adding more syntax will change that.

 

More importantly, while the editor highlighting will be a good thing (and could greatly benefit from the presence of the colon), it doesn't become strictly necessary.

It already isn't strictly necessary and it won't be with type-parameters either.

Regards,

Yaw

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f67fe5d8-21a2-4b13-ab04-2935f092d727n%40googlegroups.com.

[Yaw Boakye]

On potentially introducing backwards incompatible change, good point. I agree that we shouldn't which means the colon would be optional.

I disagree on accepting "that generic function signatures are inherently more crowded and less readable." I mean, inherently more crowded and less readable looks like something that one should apologize for (1) when teaching the language, and (2) submitting code for review. And in my experience teaching languages, some of these non-issues (to seasoned programmers) can be a real turn-off. If there's one reason people choose Go over, say, Rust, it is because of Go's readability. I honestly think it can get better, not worse. The code example I showed presents a readability challenge, and I'm not even new to Go.

Yaw

--

Curried programmer

Homepage: http://yawboakye.com

I'm tweeting when I'm not coding when I'm not holding my niece.

[Axel Wagner]

On Fri, Nov 27, 2020 at 3:42 PM Yaw Boakye <wher...@gmail.com> wrote:

I disagree on accepting "that generic function signatures are inherently more crowded and less readable." I mean, inherently more crowded and less readable looks like something that one should apologize for (1) when teaching the language, and (2) submitting code for review. And in my experience teaching languages, some of these non-issues (to seasoned programmers) can be a real turn-off. If there's one reason people choose Go over, say, Rust, it is because of Go's readability. I honestly think it can get better, not worse. The code example I showed presents a readability challenge, and I'm not even new to Go.

I didn't say there isn't an issue, I said I think the issue is inherent and thus unsolvable.

I personally definitely don't believe it would be solved by adding a colon between those parameter lists. If anything, I'd probably go back to the previous incarnation of the design, where there was still a "type" keyword in the type arguments, to make them stand out more.

[Robert Engels]

This is best solved by syntax highlighting in an editor. Doesn’t do much for b & w printed training materials - but you can achieve similar results with bold / font choice. 

On Nov 27, 2020, at 9:49 AM, 'Axel Wagner' via golang-nuts <golan...@googlegroups.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfH6BBBqZzUqzyfkMuEGoHtGq4tXdM%3DszEFUPq-QSKKXjQ%40mail.gmail.com.