Hi,
On Thu, Dec 31, 2020 at 8:59 AM wilk <w...@flibuste.net> wrote:
> If 95% of generics are collections the current draft is overkill.
> What about a simplified version with only one generic type (like we do
> with interface{}), without constraint as long as it can compile ?
>
• "Only one generic type" means you can't write generic maps or graph
structures
• "Without constraints" means compilation cost goes up significantly (as
the compiler needs to completely redo type-checking and compilation for
each instantiation - instead of only checking that the function adheres to
the constraints and the type-arguments fulfill it at each call-site. i.e.
you make an NxM problem out of an N+M problem). It also makes good error
messages very hard. And the constraints need to be documented anyway (in a
comment, if nothing else), so that the user knows how to call the function
- might as well have a standardized, machine-checkable way to express that.
So even *if* we only consider containers, the complexity of the design
isn't accidental. There are very concrete (and IMO important) advantages to
these decisions.
That being said, I also, personally, don't consider type-safe containers
the main use-case of generics. It's certainly *one*, and one that can't be
solved without them. I definitely see the advantage of being able to
implement complex data-structures like lock-free concurrent maps or sorted
maps as a library and use them in really performance-sensitive code-paths.
But I also feel that my concerns about generics mainly stem from
experiences with Java and C++ where *everything* was expressed in terms of
abstract generic containers and algorithms, cluttering the code and
requiring you to understand subtle differences between different
implementations of the implementations of the abstract versions. So,
personally, I really hope containers are *not* 95% of the use-case of
generics. In fact, if type-safe containers *where* 95% of the use-case, I
would still be very much opposed to adding generics - I don't think we
really *need* type-safety for containers, as we are usually very well aware
of what's stored in them.
Personally, the main use-case for generics I see (and I want to emphasize
that everyone sees different use-cases as more or less important, depending
on what kind of code they write) is the ability for concurrency as a
library. I think channels and goroutines are great concurrency primitives -
but they are primitives, that need to be composed to be useful. And this
composition is usually very subtle and hard to get right. So being able to
solve these composition problems once and re-use that solution, seems very
exciting to me. But, again, that focus comes from the kind of code I write.
The third use-case I see for generics is to catch bugs by being able to
express more complicated type-invariants in code. An example of that would
be type-safety for context.Value
<https://blog.merovius.de/2020/07/20/parametric-context.html> (or,
similarly but subtly different, optional interfaces of
http.ResponseWriter). However, for this use-case, I personally don't see
the value-add vs. complexity tradeoff
<https://blog.merovius.de/2017/09/12/diminishing-returns-of-static-typing.html>
as very favorable - the type-system needs a *lot* more power to catch
significantly more bugs and more power translates into a lot of complexity.
I don't think the current draft lets us express very powerful invariants.
And while I wouldn't really advocate to make that a target, I think it
would be interesting to see more discussion of this area - i.e. more
case-studies of where Go has type-safety problems and if the current design
can address them.
> func add(x, y GenericType) GenericType {
> return x + y
> }
>
> add(1,2) // add can compile : func add(x, y int) is generated
> add("abc", "def") // can compile : func add(x, y string) is generated
>
> add(1, "abc") // two differents type : error
>
> GenericType will be like interface{} but instead of casting it'll
> generate on the fly, at compile time the function with the type of each
> functions call.
> I believe it's too easy and i miss something already discussed...
>
> --
> wilk
>
> --
> 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/rsk0bb%24tg6%241%40ciao.gmane.io
> .
>
--
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/CAEkBMfGDOqWgEE2a_B9%2BqXftPc6ebBPcs_DcpsrqOvR%2BpCZ9SQ%40mail.gmail.com.
