On Fri, Nov 27, 2020 at 3:42 PM Yaw Boakye <wheres...@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. > > 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/CAEkBMfH6BBBqZzUqzyfkMuEGoHtGq4tXdM%3DszEFUPq-QSKKXjQ%40mail.gmail.com.
