On Friday, January 5, 2024 at 9:12:13 AM UTC-5 Axel Wagner wrote:
If the signature of a function says you are allowed to call the function,
you should be allowed to call the function.
While I'd argue we would be best to stick to objective arguments and not
ones that affirm the consequent, I'll nonetheless revise the proposal that
does include all knowledge in the signature, see below.
It was a conscious decision during the generics design to *not* do
type-checking of generic function bodies during instantiation time, but to
be able to compile the body of a generic function and the caller of a
generic function separately.
Unless I am misunderstanding how the compiler works, I was proposing
type-checking during compile-time, not instantiation time. Besides, prior
decisions should not in-and-of themselves eclipse hindsight
after-the-fact. As even Rob Pike said in his keynote[1] just a few days
ago, there are *"still lingering problems"* to do with generics, and
*"sometimes
it takes many years to figure something out."* So to lean into commitment
bias ensures future improvements will be less than they could be.
On to the revised proposal. Assuming your example type again:
*type X[T any] struct { T *bufio.Reader}*
Let us agree that it should not compile because of the stated conflicts.
Instead, let us assume an extension to type constraints that would allow us
to say that *"A valid type is `any` type, except for those that implement
the methods of type Y." *Using `*!*` as an placeholder sigil for that
intent, and adding the sigil `*&*`, we could have the following type
constraint:
*type Xable interface { any & !*bufio.Reader}*
*(While `!` is probably a bad choice — which is why I said it was a
placeholder — it allows me to illustrate the concept in potential code.)*
Alternately, maybe using `*-*` would be better?:
*type Xable interface { any -*bufio.Reader}*
>From the type constraint `*Xable*` it seems to me we could have the
following, which should allow the compiler to do compile-type checking,
without having to reach into deeply nested dependencies:
*type X[T Xable] struct { T *bufio.Reader}*
The above should give the OP all reasonable functionality I believe they
were requesting and usefully expand the capabilities of generics. That is,
unless there are objective arguments for why that can't reasonably be
compiled, or there are unintended conflict elsewhere in the language?
-Mike
[1] https://www.youtube.com/watch?v=yE5Tpp2BSGw
--
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/67c3cf8d-a6ae-4968-991f-df09e9f86475n%40googlegroups.com.
