" I believe over time, it will a) become clear that generic code will be less common than people think (I hope) and b) that you get used to the syntax either way. (also, yes, this has been discussed before, ad nauseam in fact :) )”
Yes I also hope that the need to generify everything is kept to an absolute minimum. Apologies about discussing things already spoken about, I have arrived fairly late to this party :) > On 28 Jun 2020, at 12:23, 'Axel Wagner' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > Readability, at the end of the day, is subjective. > So, personally: Yes, I absolutely find it more readable than any alternative > that has been suggested. Personally, when I see code using a bunch of extra > symbols that have special meaning (Perl and Haskell are extreme examples), I > tend to "zone out" and find it really hard to actually make the effort of > trying to parse it. I really like Go's general approach of using fewer > separators and keywords to convey meaning. > > But in any case: I believe over time, it will a) become clear that generic > code will be less common than people think (I hope) and b) that you get used > to the syntax either way. (also, yes, this has been discussed before, ad > nauseam in fact :) ) > > On Sun, Jun 28, 2020 at 11:16 AM Calum Shaw-Mackay > <calum.shawmac...@gmail.com <mailto:calum.shawmac...@gmail.com>> wrote: > Hi all - > > I know that there’s have been numerous threads regarding the syntax for > declaring generic types etc, and at it’s core Go is a language that can do a > lot without syntactic sugar just for the sake of it, but sometimes that > syntactic sugar helps in a fundamental way - legibility. > > Observe this function declaration > > func Combine(type T)(s []T) (T,error){ > …. > } > > Do we think that 3 consecutive clauses wrapped in parentheses is legible, > that the intent of both the function and its constraints are easily > discernible? > To me, and it is only my opinion, unless (type T) has different ‘versions’ > i.e. (struct T) or (func T), isn’t "(type " not only redundant but reduces > readability? > > Apologies if this has been discussed before. > > Calum > > > -- > 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 > <mailto:golang-nuts%2bunsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/6661399B-BF48-4D15-802C-E2B1C6C0F348%40gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/6661399B-BF48-4D15-802C-E2B1C6C0F348%40gmail.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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHO0hvNKT8tVM2tXk1trDbRFqJaGH%3DWtParweJiJQNQbg%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHO0hvNKT8tVM2tXk1trDbRFqJaGH%3DWtParweJiJQNQbg%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- 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/427170BA-3A5B-473D-B109-F7ECA275838A%40gmail.com.
