Most of the code I'd write with generics would take a func or
something satisfying an interface to set the operations if necessary.
I'd use type lists as a handy way for the user to default those to
operators. Interface literals and lambdas would be just as useful
here. I probably wouldn't bother
On Wed, Aug 5, 2020, 19:39 Tyler Compton wrote:
> On Wed, Aug 5, 2020 at 1:07 AM Jan Mercl <0xj...@gmail.com> wrote:
>
>> It's not supposed to be anything special whatsoever. Just like number
>> zero or an empty set is not some kind of an exception. It's just you
>> cannot have any reasonable
On Wed, Aug 5, 2020 at 1:07 AM Jan Mercl <0xj...@gmail.com> wrote:
> It's not supposed to be anything special whatsoever. Just like number
> zero or an empty set is not some kind of an exception. It's just you
> cannot have any reasonable set theory without it.
>
I think it's fair to say that
> I think "[type T]" is slightly clearer than "[T any]".
Code with `[T any]` is much easier to read at least for me.
среда, 5 августа 2020 г. в 11:07:59 UTC+3, Jan Mercl:
> On Tue, Aug 4, 2020 at 6:07 AM 'Carla Pfaff' via golang-nuts
> wrote:
>
> > On Tuesday, 4 August 2020 at 00:34:12 UTC+2
On Tue, Aug 4, 2020 at 6:07 AM 'Carla Pfaff' via golang-nuts
wrote:
> On Tuesday, 4 August 2020 at 00:34:12 UTC+2 ben...@gmail.com wrote:
> I'm sure it would quickly become a well-known idiom, just like people know
> that "error" is "interface{Error() string}" or "fmt.Stringer" is
>
>
> Which at first seems like a good idea, but then unless "any" is built in
>> or this becomes a well-known idiom, it won't be as self-documenting. Other
>> people will have to look up the definition to see "oh, I see, this is just
>> short-hand for an empty constraint".
>
>
> I'm sure it
>> That is an experiment. We don't seem to need the type keyword for
>> generic functions. But we do need it for generic types,
I'm used for years to look at code with generics in Java. The additional
type keyword as proposed for generics in Go in IMHO make reading the
declaration containing
On Tuesday, 4 August 2020 at 00:34:12 UTC+2 ben...@gmail.com wrote:
> Which at first seems like a good idea, but then unless "any" is built in
> or this becomes a well-known idiom, it won't be as self-documenting. Other
> people will have to look up the definition to see "oh, I see, this is
On Mon, 2020-08-03 at 10:45 -0700, Ian Lance Taylor wrote:
> Another possibility is constraints.Any, although that is no shorter
> than interface{}. I'm not sure _ is best; currently _ fairly
> consistently means "ignore this value," but in this usage it would
> mean something different.
Another
> That is an experiment. We don't seem to need the type keyword for
> generic functions. But we do need it for generic types, to avoid
> confusion with an array type (but only if there is exactly one type
> parameter with no constraint). I'm not personally a big fan of
> optional syntax, so we
On Monday, 3 August 2020 at 19:46:05 UTC+2 Ian Lance Taylor wrote:
> Yet another possibility, going back to the syntax question above, is
> requiring that a type parameter for a type alway have a constraint,
> which would mean that we would never use the "type" keyword for type
> parameters,
On Mon, Aug 3, 2020 at 1:48 AM Ben Hoyt wrote:
>
> I've played with generics a bit more, including the new square
> brackets syntax. A few notes (some of the threads have been long, so
> apologies if I'm doubling up):
Thanks for the extensive feedback.
> Related question: why does the current
I've played with generics a bit more, including the new square
brackets syntax. A few notes (some of the threads have been long, so
apologies if I'm doubling up):
1) I definitely prefer the square brackets syntax. It makes it clear
where you're using type parameters, and IMO it sets them off much
13 matches
Mail list logo
