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 On Fri, Nov 27, 2020 at 2:27 PM Axel Wagner <axel.wagner...@googlemail.com> wrote: > > > On Fri, Nov 27, 2020 at 3:14 PM wher...@gmail.com <wheres...@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+unsubscr...@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 >> <https://groups.google.com/d/msgid/golang-nuts/f67fe5d8-21a2-4b13-ab04-2935f092d727n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- *Curried programmer* *Homepage*: http://yawboakye.com I'm tweeting <https://twitter.com/@22bytes> when I'm not coding <https://github.com/yawboakye> when I'm not holding my niece. -- 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/CAPJoGXsnP8E7KLiM4QLPJ%3DKTY5ZkRJbU4gZ3S_Gn1MF3uQXpEw%40mail.gmail.com.
