Notwithstanding a concise unambiguous alternative, I would rather type parameters "stick out" so they are easily identified when visually scanning through code. I read a lot more code than I write, even as I write Go full-time.
Here are two playgrounds (that don't format/run) comparing a generic hash table implementation using [[T]] vs. [T], based on a code sample by Matt Layher <https://mdlayher.com/blog/go-generics-draft-design-building-a-hashtable/>. I don't think [[T]] is offensive to the surrounding code, and would love to know what more people think. I'm happy to see generics progressing in Go and can't wait to use it either way. [[T]] -- https://go2goplay.golang.org/p/NXqVM89QFor [T] -- https://go2goplay.golang.org/p/L9AKNHxPkUU jpap On Thursday, 16 July 2020 at 13:19:10 UTC-7 Carla Pfaff wrote: > Generics are not the most important part of the language/code. Let's not > make them stick out like a sore thumb. > On Thursday, 16 July 2020 at 22:12:17 UTC+2 jpap wrote: > >> On Thursday, 16 July 2020 at 12:51:03 UTC-7 Ian Lance Taylor wrote: >> >>> On Thu, Jul 16, 2020 at 12:41 PM joshua harr <joshu...@gmail.com> wrote: >>> > Just a note on your rationale for why not to use <: :> : >>> > "... requires more typing." Golang has, rather famously, never shied >>> away from making developers type more. The reason it hasn't, as far as I >>> understand, is that code is read far often than it is written, and so the >>> extra verbosity is worth the ease in reading the code. IMHO, that principle >>> very much applies here. The *readability* of the syntax should be a far >>> more important consideration than whether there is an extra character in >>> the syntax. >>> >>> That's a fair point. Having two characters is still in my mind a >>> disadvantage, but I agree that that disadvantage could be outweighed >>> by a gain in readability. >>> >>> That said, personally I don't find <:T:> to be any more (or less) >>> readable than [T]. >>> >>> Ian >>> >> >> I agree that readability should be a big consideration. >> >> The problem with [T] is that you need to actively read the surrounding >> code to discern between a possible array access or type parameter. I would >> prefer it to be immediately obvious so that visually scanning through code >> is as fast and clear as can be. >> >> An alternative syntax to [T] that could enable "quick looks" is [[T]]. >> It would be nice to use <<T>>, but that has parsing ambiguities with the >> existing bit-shift operator, just as <T> is ambiguous with the comparison >> operator. >> >> The burden of typing the same character twice on a keyboard in quick >> succession for [[T]] is more or less the same as the single-character >> version [T] and less so than two-character delimiters like <: and :>, and >> especially those delimiters that require the shift-key in play at the same >> time. >> >> jpap >> >> -- 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/987b9cc1-e35c-4a5f-a25d-61c21c4bdd91n%40googlegroups.com.
