I like it!
BTW, I don't understand the meaning of this comment in the commit log:
> >> Experiment: Make "type" keyword optional in generic type declarations when
> >> it is clear that we can't have an array type declaration.
It is talking about defining generic arrays, where one parameter may b
On Thu, Jul 23, 2020 at 1:12 AM Aleksey Tulinov
wrote:
>
> First of all, thank you for taking your time to answer this topic. I
> know some stuff i say is dumb, i appreciate your patience.
>
> To answer your question: i would assume that OR is about as useful as
> AND or NOT.
>
> type Constraint i
Ian,
First of all, thank you for taking your time to answer this topic. I
know some stuff i say is dumb, i appreciate your patience.
To answer your question: i would assume that OR is about as useful as
AND or NOT.
type Constraint interface {
Sequence && !Channel
}
With that said. So far i'm
On Wed, Jul 22, 2020 at 9:41 PM Aleksey Tulinov
wrote:
>
> This is Java-style inheritance. It isn't bad, but i think that
> C++-style composition is somehow more in the spirit of Go. Strictly
> personal opinion of course. Older proposal described constraints as
> expressions, so to me it appears s
I'm not sure if i understood everything correctly.
type structField(type T) struct {
a int
x T
}
But this is a generic type, not a constraint for a type, isn't it?
Constraint is this:
type Custom interface{
type int, float64, uint64
}
type structField(type T Custom) interface {
ty
Hey! I would like to join the discussion and add my 5 cents here, since I
have been criticizing the contracts draft and I would like to show what
were my points in order to support the current design draft.
I believe the original problem for the generics is to allow the same
function to work
On Wed, Jul 22, 2020 at 5:12 PM Aleksey Tulinov
wrote:
>
> Hmm. I must have read the previous version, but it probably was some
> time ago. I have to say that i like the previous version more than the
> current one.
>
> I definitely don't like this:
>
> type structField interface {
> type struct
Hmm. I must have read the previous version, but it probably was some
time ago. I have to say that i like the previous version more than the
current one.
I definitely don't like this:
type structField interface {
type struct { a int; x int },
struct { b int; x float64 },
struct { c int;
On Wed, Jul 22, 2020 at 1:46 PM Aleksey Tulinov
wrote:
>
> I'm not really a language designer and i don't use Go extensively, so
> please take my words with a grain of salt. But I like Go and would
> like to use it, and I'd like to put my 2 cents into the jar. I'm sorry
> if this was already discu
Hello Calum,
One FYI that Tyler Compton pulled together a helpful list of dozen or so
different alternative generics syntax suggestions along with their
corresponding recent golang-nuts threads:
https://groups.google.com/d/msg/golang-nuts/uQDrcHDwT_w/Y-Myzuw_AQAJ
That could be a helpful st
" I believe over time, it will a) become clear that generic code will be less
common than people think (I hope) and b) that you get used to the syntax either
way. (also, yes, this has been discussed before, ad nauseam in fact :) )”
Yes I also hope that the need to generify everything is kept to
Readability, at the end of the day, is subjective.
So, personally: Yes, I absolutely find it more readable than any
alternative that has been suggested. Personally, when I see code using a
bunch of extra symbols that have special meaning (Perl and Haskell are
extreme examples), I tend to "zone out"
12 matches
Mail list logo
