Re: [go-nuts] [generics] Separating type parameters, regular parameters, and return parameters

2020-11-27 Thread 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 
>  wrote:
> 
> 
>> On Fri, Nov 27, 2020 at 3:42 PM Yaw Boakye  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  
>>> wrote:
>>> 
>>> 
 On Fri, Nov 27, 2020 at 3:14 PM 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+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.
>> 
>> 
>> -- 
>> Curried programmer
>> Homepage: http://yawboakye.com
>> I'm tweeting when I'm not coding 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.

-- 
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/74BD5B09-82DF-4F88-8BCC-5C7850E29B9F%40ix.netcom.com.

Re: [go-nuts] [generics] Separating type parameters, regular parameters, and return parameters

2020-11-27 Thread 'Axel Wagner' via golang-nuts 
On Fri, Nov 27, 2020 at 3:42 PM Yaw Boakye  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 
> wrote:
>
>>
>>
>> On Fri, Nov 27, 2020 at 3:14 PM 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+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
>>> 
>>> .
>>>
>>
>
> --
> *Curried programmer*
> *Homepage*: http://yawboakye.com
> I'm tweeting  when I'm not coding
>  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.

Re: [go-nuts] [generics] Separating type parameters, regular parameters, and return parameters

2020-11-27 Thread 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

On Fri, Nov 27, 2020 at 2:27 PM Axel Wagner 
wrote:

>
>
> On Fri, Nov 27, 2020 at 3:14 PM 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+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
>> 
>> .
>>
>

-- 
*Curried programmer*
*Homepage*: http://yawboakye.com
I'm tweeting  when I'm not coding
 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.

Re: [go-nuts] [generics] Separating type parameters, regular parameters, and return parameters

2020-11-27 Thread 'Axel Wagner' via golang-nuts 
On Fri, Nov 27, 2020 at 3:14 PM 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+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
> 
> .
>

-- 
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/CAEkBMfGQWDfM%3DawMyiZpFe_8d8rHGWyo9xeY87As7dWoj1qw2g%40mail.gmail.com.