I'm Sorry -- when I said "readability reviewer" I was referring to a very
google-specific term about how they ensure the author of a change
understands the language they're writing. Granted, it's been a while since
I worked there but, at that time, each change request (aka MR, PR, etc...)
requi
On Tue, Aug 9, 2022 at 1:52 PM Tim Peoples wrote:
> Yeah, I'm with Burak on this one. The interface usage you're describing
> Henry is exactly the kind of thing I'm talking about. While on the surface
> it may seem advantageous -- in fact, I also tried writing Go that way when
> I first started
Yeah, I'm with Burak on this one. The interface usage you're describing
Henry is exactly the kind of thing I'm talking about. While on the surface
it may seem advantageous -- in fact, I also tried writing Go that way when
I first started -- my *readability* reviewers at Google did well to
enli
One significant argument against preemptive interfaces is that you can't
add a method to an interface type without breaking compatibility.
Also, an interface is significantly less amenable to static analysis
because it's not certain where a method call is implemented.
One concern I have about the
On Mon, Aug 8, 2022 at 11:27 PM Henry wrote:
> I am sure that many of us have been on that journey. After using Go for
> some time, we discover some practices that are not necessarily in agreement
> with the existing "adages" but effectively solve our problems.
>
> For me, if the data type is mut
I still assert that your problem is not really anything to do with
generics, because you'd find the same problem even if you hard-coded to
float32 and didn't have any generics at all (try it). I also don't
understand what you're proposing to change.
The main thing you seem to be concerned about
What you appear to be after is a recursive relationship with union types:
"S is a slice type, each of whose elements are either of type S or some
type T".
Exactly this is what I'm trying to emphasize: since I'm opting to use the
explicit generic type inference, I would expect the type system
I don't know if there's much that can be done about this, but thought I'd
mention it anyway.
Suppose you're trying to make a parameterised type, like
type Elem[T any] blah...
ex: https://go.dev/play/p/1tS1SCxTFP-
but you forget the "any", and just write
type Elem[T] blah...
ex: https://go.dev/pl
Example of type inference in action:
https://go.dev/play/p/pL7_8zaFIZN
What you appear to be after is a recursive relationship with union types:
"S is a slice type, each of whose elements are either of type S or some
type T". AFAIK Go's type system isn't rich enough for that: hence for
heterog
As far as I can see, the problem isn't anything to do with generics, but
with this line alone:
input := []any{[]float32{1.0, 2.0}, 1.1}
See:
https://go.dev/play/p/gUqmUb-Vs_y
You've made a slice with mixed elements. One happens to be a slice of
float32's, and the other happens to be a float64.
Let's consider the following situation:
I have generic function which can accepts function arguments defined as
any. Now if want to know exactly the type of function arguments I have to
use the reflect package. The problem is that although on function
invocation we can explicitly define the typ
Let's consider the following situation:
I have generic function which can accepts function arguments defined as
any. Now if want to know exactly the type of function arguments I have to
use the reflect package. The problem is that although on function
invocation we can explicitly define the typ
12 matches
Mail list logo
