Hello everyone,
First and foremost, thanks a lot for putting this together, it's been
amazing.
I just wanted to let you guys know that generics is looking very promising
for me.
Without generics, my codebase has things like:
map_user, map_country, map_state etc, they basically take a collection o
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
I just discovered the experiment to make the "type" keyword optional in
certain cases on the dev.go2go branch. The commit message says:
---
Experiment: Make "type" keyword optional in generic type declarations
when
it is clear that we can't have an array type declaration. This is the
ca
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
Hi,
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 discussed, I checked the mailing list but didn't
find this.
I've
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"
Hi all -
I know that there’s have been numerous threads regarding the syntax for
declaring generic types etc, and at it’s core Go is a language that can do a
lot without syntactic sugar just for the sake of it, but sometimes that
syntactic sugar helps in a fundamental way - legibility.
Observe
https://go2goplay.golang.org/p/Ol5mbIbiZhX works good enough, finally a way
to make go usable for my cases(work with collections)!
There are two main things that we hope to learn
1) First, does generic code make sense? Does it feel like Go? What
surprises do people encounter? Are the error messa
17 matches
Mail list logo
