Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

[Ian Lance Taylor]

On Tue, Jan 19, 2021 at 4:36 AM Kevin Chadwick  wrote:
>
> On 1/19/21 12:21 PM, Axel Wagner wrote:
> > And, of course, you can change the suggested syntax again. But every time 
> > you do
> > a change like that, you are flushing the entire previous discussion down the
> > drain, because we now have to re-consider all aspects of the design, from
> > tokenization, over parsing to type-checking and implementation etc.
>
> OK, but using a T all over the place, sucks.

Note that that's just a stylistic convention.  We've gone back and
forth on that convention even while keeping the rest of the syntax the
same.

Basically, in a design like the current issue 43651 proposal, type
parameters have a name.  What should that name be?  We've currently
settled on names like "T".  But they could just as well be names like
"element" or "number".  The proposal permits writing code like

func Find[element comparable](s []element, val element) int {
...
}

func Min[number constraints.Ordered](a, b number) number {
   ...
}

Ian

-- 
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/CAOyqgcVQ6TtqLX5OG4A%2BdEG0oJvJF-uKwFAgv%2Bqdpw8Oq-nDBQ%40mail.gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

['Carla Pfaff' via golang-nuts]

On Tuesday, 19 January 2021 at 15:39:25 UTC+1 m8il...@gmail.com wrote:

> Seems to me that most generics implementations use a capital letter 
> abstracted type syntax that I hate.
>

This is just a convention and not part of the syntax, which means it's 
irrelevant to the discussion about the proposal. You can easily use 
lowercase letters/identifiers: https://go2goplay.golang.org/p/eWgJSLNTZw8

-- 
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/2e2593bd-f88e-4d2e-9ebe-0949cb00688bn%40googlegroups.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

[Kevin Chadwick]

>Apologies then. I assumed you where trying to amend OPs suggestion,
>which
>was specifically to abscond with type parameters and the ability to
>express
>constraints.
>Note the topic of this thread: »instead of generics, why cant we just
>implement an "any" builtin?«

Oops, Sorry for hijacking the thread without changing the title. I do that too 
often when being whimsically inquisitive.

-- 
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/67D43CEB-2576-4A9E-939D-DDE2B3CC07D2%40gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

['Axel Wagner' via golang-nuts]

On Tue, Jan 19, 2021 at 6:08 PM Kevin Chadwick  wrote:

> I believe my suggestion included constraints in the function parameter list
> whilst avoiding the needless abstraction?
>

Apologies then. I assumed you where trying to amend OPs suggestion, which
was specifically to abscond with type parameters and the ability to express
constraints.
Note the topic of this thread: »instead of generics, why cant we just
implement an "any" builtin?«


>
> --
> 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/56a0130c-64d5-c4a8-ddda-9d22abd99565%40gmail.com
> .
>

-- 
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/CAEkBMfG6w5hDB6ERq1OWCFuqP1f4awQpCpwaRXTMi_19v80A2g%40mail.gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

[Kevin Chadwick]

On 1/19/21 4:53 PM, Axel Wagner wrote:
> 
> Yes. And there are definitely syntactical choices that can be decoupled - like
> how we went from `(type T)` to `[T any]`. Not having type parameters or ways 
> to
> constrain them, though, is more than just a syntactical choice. It removes the
> actual core of the design. Of the ten bullet points in the high-level design
> description

I believe my suggestion included constraints in the function parameter list
whilst avoiding the needless abstraction?

-- 
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/56a0130c-64d5-c4a8-ddda-9d22abd99565%40gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

['Axel Wagner' via golang-nuts]

On Tue, Jan 19, 2021 at 5:16 PM Kevin Chadwick  wrote:

> On 1/19/21 3:32 PM, Axel Wagner wrote:
>
> > "I think this design sucks, you should throw it away and start from
> scratch"
> I assume you believe that is what I affectively said


I think it is what OP has effectively said. The design is called "generic
programming using type parameters" and they suggested not having type
parameters.


> There is obviously a lot more than syntax to the proposal.
>

Yes. And there are definitely syntactical choices that can be decoupled -
like how we went from `(type T)` to `[T any]`. Not having type parameters
or ways to constrain them, though, is more than just a syntactical choice.
It removes the actual core of the design. Of the ten bullet points in the
high-level design description
,
9 are directly tied to the semantics of type-parameters and their
constraints (the only exception is `any`, which is just a minor syntactical
convenience, which I would even call irrelevant to the design).

Perhaps the requirements and syntax should be separate proposals. Though
> Ians
> remarks make it sound like most if not all of the requirements may have
> been
> finalised a while ago?
>

I don't think so. Some requirements are definitely non-negotiable. Some, I
hope, can still be dropped (though I'm not very optimistic). Some,
definitely, could still be added - after all, one of the express purposes
of publishing the draft and the prototype, is to let people experiment and
bring up things that they want to do, but can't, using the design.

But also, yes. Ten years is a long time to talk about what generics must be
able to provide and what restrictions they must not impose. And at some
point, to make progress, you must commit to something. So if you want to
re-negotiate some of the more basic requirements, you likely need to make a
very good case.

I am certainly not sold on the idea that an "idiomatic" interface like
> approach
> is going to be less rather than more confusing (removing upvote).
>
> --
> 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/c73f30e4-558a-b7e4-5706-d879936e68d0%40gmail.com
> .
>

-- 
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/CAEkBMfGE9V2Mc1X1oTUC44B1TbPVhF-2GfniDjtMHnGjpTYGWA%40mail.gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

[Kevin Chadwick]

On 1/19/21 3:32 PM, Axel Wagner wrote:

> "I think this design sucks, you should throw it away and start from scratch"
I assume you believe that is what I affectively said but I am not sure if I were
in a position of understanding all of the requirements and details, that I would
agree? I gave a preferred syntax example with a caveat of lacking understanding
of the implications. There is obviously a lot more than syntax to the proposal.
Perhaps the requirements and syntax should be separate proposals. Though Ians
remarks make it sound like most if not all of the requirements may have been
finalised a while ago?

I am certainly not sold on the idea that an "idiomatic" interface like approach
is going to be less rather than more confusing (removing upvote).

-- 
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/c73f30e4-558a-b7e4-5706-d879936e68d0%40gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

['Axel Wagner' via golang-nuts]

On Tue, Jan 19, 2021 at 3:39 PM Kevin Chadwick  wrote:

> Sure, but the Go team needs to be realistic and realise that not everyone
> is on
> the salary that they are or can afford the time that they can, or even on a
> consistent salary at all (e.g. founder with two jobs).


People only having limited time is exactly my point. Re-litigating the same
arguments over and over again is a drain on everyone's time as well.

And it is possible to meaningfully participate in the design process
without being paid to do so. I don't get paid to participate in the process
either. The time I can spend on it is thus limited. And I've decided that
the best use of my time is to try and make the existing design better,
instead of attempting to throw it out and write my own.

The uncomfortable truth is, that you can't design a major language feature
like Generics for a popular language like Go from scratch, without
investing significant time into it. *Someone* needs to do it - and it's
unreasonable to expect others to do it on your terms.


> Casual observations are not worthless and you don't need to have the
> answers to know something may seem sub optimal!
>

Both of these are true. But "I think this design sucks, you should throw it
away and start from scratch" is not actionable. It neither makes a strong
case for *why* they should start over, nor does it provide a viable
alternative to switch *to*.

Casual observations *can* be very helpful, even if you don't have the
answer. For example, if there is something that you want to do with
generics, but can't with this design, it's perfectly reasonable to make
that observation - even if you don't know how to fit a solution to your
problem into the design.

A casual "I don't like this design and would prefer not to add generics" is
also helpful (as I said). It's still not very actionable - there is nothing
we can do to change your mind, if we feel differently - but at least your
vote can be tallied and give an impression of how the community feels.

A casual "here is the sketch of an idea that has not been considered
before" is also very helpful, even without a full idea of how to implement
it. As long as it actually has not been considered before and as long as it
at least superficially seems feasible.

And my original response was exactly to point out why OP's suggestion does
not seem to even superficially be feasible.

After ten years of waiting for the "right" generics. This isn't the time to
> disregard the option of fundamental changes.


I don't think anyone is disregarding that option - or the option of not
adding generics to Go at all. In fact, I feel I was pretty clear that I at
least am willing to consider a completely different design - as long as it
actually takes the form of a fully-fledged design.


> p.s. I had already upvoted the proposal actually, as it is certainly well
> considered and well constrained.


FWIW, I haven't, because there are still very fundamental aspects of the
design I'd prefer to change. So I have neither up- nor downvoted and
instead commented with my concerns.




> --
> 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/1c1ab297-7165-3cc7-e964-20dc74b3eec6%40gmail.com
> .
>

-- 
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/CAEkBMfEExA9Gb2WOnR4n%3DadH65%3DuWa5xQkz8F5tG-yBRy0pzYw%40mail.gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

[Kevin Chadwick]

On 1/19/21 1:41 PM, Axel Wagner wrote:
> 
> OK, but using a T all over the place, sucks.
> 
> 
> That is a fair opinion to hold. But if you don't like the current design and
> want an alternative (or nothing at all) to happen, the strategy of just saying
> "it sucks" just isn't going to be very effective towards that goal. Because
> you'll need to actually get specific people on board for that and they are
> unlikely to get swayed by simplistic rhetoric like that.

Sure, but the Go team needs to be realistic and realise that not everyone is on
the salary that they are or can afford the time that they can, or even on a
consistent salary at all (e.g. founder with two jobs). Casual observations are
not worthless and you don't need to have the answers to know something may seem
sub optimal!

I expected a discussed already response.

>> And, of course, you can change the suggested syntax again. But every time you
>> do a change like that, you are flushing the entire previous discussion down
>> the drain, because we now have to re-consider all aspects of the design, from
>> tokenization, over parsing to type-checking and implementation etc.

After ten years of waiting for the "right" generics. This isn't the time to
disregard the option of fundamental changes. On the contrary, being so close to
it, might be blinding (Ian does seem to be open minded however). Seems to me
that most generics implementations use a capital letter abstracted type syntax
that I hate. This is thankfully conservative but isn't exactly thinking outside
the box for an implementation, that is just right. It may be that there are
unavoidable reasons for that abstraction but it looks like needless abstraction,
on the face of it.

p.s. I had already upvoted the proposal actually, as it is certainly well
considered and well constrained.

-- 
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/1c1ab297-7165-3cc7-e964-20dc74b3eec6%40gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

['Axel Wagner' via golang-nuts]

On Tue, Jan 19, 2021 at 1:36 PM Kevin Chadwick  wrote:

> On 1/19/21 12:21 PM, Axel Wagner wrote:
> > And, of course, you can change the suggested syntax again. But every
> time you do
> > a change like that, you are flushing the entire previous discussion down
> the
> > drain, because we now have to re-consider all aspects of the design, from
> > tokenization, over parsing to type-checking and implementation etc.
>
> OK, but using a T all over the place, sucks.
>

That is a fair opinion to hold. But if you don't like the current design
and want an alternative (or nothing at all) to happen, the strategy of just
saying "it sucks" just isn't going to be very effective towards that goal.
Because you'll need to actually get specific people on board for that and
they are unlikely to get swayed by simplistic rhetoric like that.


> --
> 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/f6e17dd3-91d5-39eb-7aa2-42f8058f13af%40gmail.com
> .
>

-- 
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/CAEkBMfEB1sBiWMJH0MhMx1CGmaAsvGxQk0_MyY5CxBAf0Em39Q%40mail.gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

[Artur Vianna]

He gave an idea and i found it *fun* to think of the implementation, i'm
not proposing anything, in fact i wrote and deleted from my original text
"This has probably been thought already", because it looked like i was
proposing, and I'm not.

On Tue, 19 Jan 2021, 09:21 'Axel Wagner' via golang-nuts, <
golang-nuts@googlegroups.com> wrote:

> Instead of giving one-off answers to one-off questions, I would suggest to
> write a detailed design doc, so we can talk about *that*. The design
> draft by Ian and Robert is the culmination of over a decade of thinking and
> talking about generics in Go and it goes to great lengths to shed light on
> all aspects of the design - from syntax, over type-checking and
> type-inference to actual implementation considerations. That is, why it is
> so long - its length doesn't reflect the complexity of the design, but it
> reflects the complexity of the discussion.
>
> It certainly is possible to come up with a simpler design and it might
> even be possible to come up with a simpler design that does more. But if
> the premise you are coming into the discussion with is "let's just assume
> that the last ten years of discussion did not happen and start from
> scratch", you are *highly* likely to duplicate effort that has already
> been done. And if you walk through your design on a mailing list, instead
> of putting in the work of writing a full design doc, you are forcing others
> to do this duplicate effort - in the form of exactly such one-off question
> and answers.
>
> Please take a note of the evolution of this generics design. For a long
> time now, the progression has been a) Ian writes down a design, b) the
> benefits and merits of this design where then discussed *holistically*,
> under consideration of all aspects of the design and c) Ian came back a
> year later with a new design, taking the discussion of the previous one
> into consideration. This means that at every stage, we could talk about a
> specific design in its entirety, without the danger of forgetting the
> implications of changing one aspect of it has on the other aspects.
>
> It's easy to come up with simpler syntax. It's also easy to answer
> questions about how specific problems of that syntax would be addressed.
> But often this means changing aspects of the design - for example, you are
> now suggesting, changing the syntax to allow new type-literals using new
> keywords or predeclared identifiers. The obvious follow-up is then "how
> about the second parameter? Or the nth?". And, of course, you can change
> the suggested syntax again. But every time you do a change like that, you
> are flushing the entire previous discussion down the drain, because we now
> have to re-consider all aspects of the design, from tokenization, over
> parsing to type-checking and implementation etc.
>
> So, I strongly urge y'all to either a) work with the rest of the community
> on the draft posted by Ian and Robert, trying to improve on it, or b) write
> your own design, in a detailed document about all aspects of it, or c) do
> neither and stick with a pure thumbs-up/down expression of opinion - which
> doesn't help to address your concerns, but at least counting those is
> scaleable.
>
> On Tue, Jan 19, 2021 at 12:50 PM Kevin Chadwick 
> wrote:
>
>> On 1/19/21 11:43 AM, 'Axel Wagner' via golang-nuts wrote:
>> > This is essentially the previous generics design
>> > <
>> https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md
>> >,
>> > where you implicitly use the function body as a contract - with the
>> exception,
>> > that you have no way to express that two arguments should be *different*
>>
>> firstInput[0]
>> firstInput[[]byte]
>>
>> --
>> 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/91fee76b-922c-fd1c-f177-65c9251c6992%40gmail.com
>> .
>>
> --
> 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/CAEkBMfGv8q3c8tXZha%2BVg1mO46WZqi_RTub%2BBGWT6OgrmPk7RA%40mail.gmail.com
> 
> .
>

-- 
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 

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

[Kevin Chadwick]

On 1/19/21 12:21 PM, Axel Wagner wrote:
> And, of course, you can change the suggested syntax again. But every time you 
> do
> a change like that, you are flushing the entire previous discussion down the
> drain, because we now have to re-consider all aspects of the design, from
> tokenization, over parsing to type-checking and implementation etc.

OK, but using a T all over the place, sucks.

-- 
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/f6e17dd3-91d5-39eb-7aa2-42f8058f13af%40gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

['Axel Wagner' via golang-nuts]

Instead of giving one-off answers to one-off questions, I would suggest to
write a detailed design doc, so we can talk about *that*. The design draft
by Ian and Robert is the culmination of over a decade of thinking and
talking about generics in Go and it goes to great lengths to shed light on
all aspects of the design - from syntax, over type-checking and
type-inference to actual implementation considerations. That is, why it is
so long - its length doesn't reflect the complexity of the design, but it
reflects the complexity of the discussion.

It certainly is possible to come up with a simpler design and it might even
be possible to come up with a simpler design that does more. But if the
premise you are coming into the discussion with is "let's just assume that
the last ten years of discussion did not happen and start from scratch",
you are *highly* likely to duplicate effort that has already been done. And
if you walk through your design on a mailing list, instead of putting in
the work of writing a full design doc, you are forcing others to do this
duplicate effort - in the form of exactly such one-off question and answers.

Please take a note of the evolution of this generics design. For a long
time now, the progression has been a) Ian writes down a design, b) the
benefits and merits of this design where then discussed *holistically*,
under consideration of all aspects of the design and c) Ian came back a
year later with a new design, taking the discussion of the previous one
into consideration. This means that at every stage, we could talk about a
specific design in its entirety, without the danger of forgetting the
implications of changing one aspect of it has on the other aspects.

It's easy to come up with simpler syntax. It's also easy to answer
questions about how specific problems of that syntax would be addressed.
But often this means changing aspects of the design - for example, you are
now suggesting, changing the syntax to allow new type-literals using new
keywords or predeclared identifiers. The obvious follow-up is then "how
about the second parameter? Or the nth?". And, of course, you can change
the suggested syntax again. But every time you do a change like that, you
are flushing the entire previous discussion down the drain, because we now
have to re-consider all aspects of the design, from tokenization, over
parsing to type-checking and implementation etc.

So, I strongly urge y'all to either a) work with the rest of the community
on the draft posted by Ian and Robert, trying to improve on it, or b) write
your own design, in a detailed document about all aspects of it, or c) do
neither and stick with a pure thumbs-up/down expression of opinion - which
doesn't help to address your concerns, but at least counting those is
scaleable.

On Tue, Jan 19, 2021 at 12:50 PM Kevin Chadwick  wrote:

> On 1/19/21 11:43 AM, 'Axel Wagner' via golang-nuts wrote:
> > This is essentially the previous generics design
> > <
> https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md
> >,
> > where you implicitly use the function body as a contract - with the
> exception,
> > that you have no way to express that two arguments should be *different*
>
> firstInput[0]
> firstInput[[]byte]
>
> --
> 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/91fee76b-922c-fd1c-f177-65c9251c6992%40gmail.com
> .
>

-- 
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/CAEkBMfGv8q3c8tXZha%2BVg1mO46WZqi_RTub%2BBGWT6OgrmPk7RA%40mail.gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

[Artur Vianna]

Actually i thought it would be more complex than the current design, but a
simpler api. I didn't know types could be created at runtime, this seems to
scale up the problem by an order of magnitude.

ps: sorry, forgot to hit "Reply all"

On Tue, 19 Jan 2021, 08:44 Axel Wagner, 
wrote:

> On Tue, Jan 19, 2021 at 12:19 PM Artur Vianna 
> wrote:
>
>> if you're trying to compare "a> store this as a operation necessary for that type to work, as an *implicit
>> contract*. And whenever this function is used, it checks this implicit
>> contract(s) with every type and fails to compile if it doesn't conform.
>>
>
> This is essentially the previous generics design
> ,
> where you implicitly use the function body as a contract - with the
> exception, that you have no way to express that two arguments should be
> *different* (but specific) types, with different operations. You also don't
> have the ability to, say, make a slice of one of the argument types (which
> is necessary to implement many practical algorithms) - in `func (a, b
> any)`, how would you express "a slice of the type of a, whichever that is"?
> It's also extremely hard to tell what changes you can make to a function
> without changing it's API, because now, every line of code in it is part of
> that. Lastly, it also opens up practical questions about how to efficiently
> type-check such a program and give meaningful error messages.
>
> So, in practice, this idea may look simpler than actual generics. But it
> really isn't. It still has most of the actual complexity in practice, while
> *also* reducing their expressive powers and bringing up now and hard to
> solve problems.
>
> Similar how you can't compare two slices and it fails to compile, because
>> slices aren't comparable. Internally the compiler would need the
>> information on every possible operation on every type, but i guess this
>> partly exists already, as part of the static checking.
>>
>
> Not all types are static. It is possible to create new types using
> `reflect`.
>
> Then, analyzing the types used on this function through the code, it
>> generates an equivalent function for every type (if you use string and int,
>> it generates code for string and int), and then compiles.
>>
>> tldr: Lookup every function call with "any". Extract the types. Lookup in
>> a table the possible operations on each type. If allowed, generate specific
>> code for those types. Compile normally (?).
>>
>> On Tue, 19 Jan 2021, 04:40 'Axel Wagner' via golang-nuts, <
>> golang-nuts@googlegroups.com> wrote:
>>
>>> Hi,
>>>
>>> On Tue, Jan 19, 2021 at 6:47 AM mortdeus  wrote:
>>>
 The more I look at the proposed generic syntax the more I feel like a
 texan fearing the californian relocation to my state. In other words I am
 feeling like Go had something awesome and extremely conservative going on
 in terms of syntax and because people from other super convoluted languages
 are coming over (which their leaving should say a lot about their said
 language) and they don't have their one "to die for" feature from their old
 language they are expecting us to conform.

>>>
>>> You should keep in mind, then, that the generics design is driven by a)
>>> one of the original designers of Go and b) one of the first people to join
>>> the Go project after those original designers (long before the language was
>>> open source).
>>>
>>> So, if that analogy is apt, then only because Texans appropriated their
>>> land from Native Americans and have no right to feel entitled to it.
>>>
>>> The reality I want to ask is whether any of the designers of the
 language actually want this feature to the point that they want to be
 looking at said feature all day, every day when they are working on other
 people's code, or are they just conforming because so many people are
 asking for a feature, and they feel a desire to give the people what they
 ask for, without considering the fact that the majority doesn't always
 consider the implications of what they ask for?
>>>
>>>
>>> That has been asked a bunch of times by people opposing generics - the
>>> last time is was roughly two weeks ago and caused a discussion that spanned
>>> 187 messages over two threads
>>> https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo
>>> https://groups.google.com/g/golang-nuts/c/bj6kMQBTqUY
>>>
>>> So, the answer is: Yes. This is a feature wanted by the original
>>> designers of Go and there is evidence of that from long before Go was open
>>> sourced.
>>>
>>>
 What I mean is to just give us an omnipotent "any" builtin type and to
 make those special case functions that get extra attention by the runtime.

 func sort(a, b any){
 if a < b{
 lots of pre defined magic happens
 }

>>>
>>> If that was a solution to the kind of problems generics solve, we would
>>> already be using it. `type any = 

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

[Kevin Chadwick]

On 1/19/21 11:43 AM, 'Axel Wagner' via golang-nuts wrote:
> This is essentially the previous generics design
> ,
> where you implicitly use the function body as a contract - with the exception,
> that you have no way to express that two arguments should be *different*

firstInput[0]
firstInput[[]byte]

-- 
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/91fee76b-922c-fd1c-f177-65c9251c6992%40gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

['Axel Wagner' via golang-nuts]

On Tue, Jan 19, 2021 at 12:19 PM Artur Vianna 
wrote:

> if you're trying to compare "a this as a operation necessary for that type to work, as an *implicit
> contract*. And whenever this function is used, it checks this implicit
> contract(s) with every type and fails to compile if it doesn't conform.
>

This is essentially the previous generics design
,
where you implicitly use the function body as a contract - with the
exception, that you have no way to express that two arguments should be
*different* (but specific) types, with different operations. You also don't
have the ability to, say, make a slice of one of the argument types (which
is necessary to implement many practical algorithms) - in `func (a, b
any)`, how would you express "a slice of the type of a, whichever that is"?
It's also extremely hard to tell what changes you can make to a function
without changing it's API, because now, every line of code in it is part of
that. Lastly, it also opens up practical questions about how to efficiently
type-check such a program and give meaningful error messages.

So, in practice, this idea may look simpler than actual generics. But it
really isn't. It still has most of the actual complexity in practice, while
*also* reducing their expressive powers and bringing up now and hard to
solve problems.

Similar how you can't compare two slices and it fails to compile, because
> slices aren't comparable. Internally the compiler would need the
> information on every possible operation on every type, but i guess this
> partly exists already, as part of the static checking.
>

Not all types are static. It is possible to create new types using
`reflect`.

Then, analyzing the types used on this function through the code, it
> generates an equivalent function for every type (if you use string and int,
> it generates code for string and int), and then compiles.
>
> tldr: Lookup every function call with "any". Extract the types. Lookup in
> a table the possible operations on each type. If allowed, generate specific
> code for those types. Compile normally (?).
>
> On Tue, 19 Jan 2021, 04:40 'Axel Wagner' via golang-nuts, <
> golang-nuts@googlegroups.com> wrote:
>
>> Hi,
>>
>> On Tue, Jan 19, 2021 at 6:47 AM mortdeus  wrote:
>>
>>> The more I look at the proposed generic syntax the more I feel like a
>>> texan fearing the californian relocation to my state. In other words I am
>>> feeling like Go had something awesome and extremely conservative going on
>>> in terms of syntax and because people from other super convoluted languages
>>> are coming over (which their leaving should say a lot about their said
>>> language) and they don't have their one "to die for" feature from their old
>>> language they are expecting us to conform.
>>>
>>
>> You should keep in mind, then, that the generics design is driven by a)
>> one of the original designers of Go and b) one of the first people to join
>> the Go project after those original designers (long before the language was
>> open source).
>>
>> So, if that analogy is apt, then only because Texans appropriated their
>> land from Native Americans and have no right to feel entitled to it.
>>
>> The reality I want to ask is whether any of the designers of the language
>>> actually want this feature to the point that they want to be looking at
>>> said feature all day, every day when they are working on other people's
>>> code, or are they just conforming because so many people are asking for a
>>> feature, and they feel a desire to give the people what they ask for,
>>> without considering the fact that the majority doesn't always consider the
>>> implications of what they ask for?
>>
>>
>> That has been asked a bunch of times by people opposing generics - the
>> last time is was roughly two weeks ago and caused a discussion that spanned
>> 187 messages over two threads
>> https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo
>> https://groups.google.com/g/golang-nuts/c/bj6kMQBTqUY
>>
>> So, the answer is: Yes. This is a feature wanted by the original
>> designers of Go and there is evidence of that from long before Go was open
>> sourced.
>>
>>
>>> What I mean is to just give us an omnipotent "any" builtin type and to
>>> make those special case functions that get extra attention by the runtime.
>>>
>>> func sort(a, b any){
>>> if a < b{
>>> lots of pre defined magic happens
>>> }
>>>
>>
>> If that was a solution to the kind of problems generics solve, we would
>> already be using it. `type any = interface{}` is easy to write. But it's
>> not - it a) doesn't express the constraints that both types have to be the
>> same, b) doesn't express the constraint that this type is the same of the
>> slice passed to Sort (I assume you meant to call your function less) and c)
>> doesn't allow you to express constraints on such types that *aren't* "it
>> can be anything".
>>
>> I think it isn't too much to ask to at 

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

[Kevin Chadwick]

On 1/19/21 11:19 AM, Artur Vianna wrote:
> Similar how you can't compare two slices and it fails to compile, because 
> slices
> aren't comparable. Internally the compiler would need the information on every
> possible operation on every type, but i guess this partly exists already, as
> part of the static checking.

I'm not tuned into the requirements of the Generics proposal, however.

I would like the syntax of.

func (String|[]byte input, myType|publicKey secondInput){
}

-- 
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/54f1c29a-3328-623a-a83b-9e312b658b27%40gmail.com.

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

[Artur Vianna]

Not taking anyone's side here, but here's a example of how i think this
"any" may work:

if you're trying to compare "a wrote:

> Hi,
>
> On Tue, Jan 19, 2021 at 6:47 AM mortdeus  wrote:
>
>> The more I look at the proposed generic syntax the more I feel like a
>> texan fearing the californian relocation to my state. In other words I am
>> feeling like Go had something awesome and extremely conservative going on
>> in terms of syntax and because people from other super convoluted languages
>> are coming over (which their leaving should say a lot about their said
>> language) and they don't have their one "to die for" feature from their old
>> language they are expecting us to conform.
>>
>
> You should keep in mind, then, that the generics design is driven by a)
> one of the original designers of Go and b) one of the first people to join
> the Go project after those original designers (long before the language was
> open source).
>
> So, if that analogy is apt, then only because Texans appropriated their
> land from Native Americans and have no right to feel entitled to it.
>
> The reality I want to ask is whether any of the designers of the language
>> actually want this feature to the point that they want to be looking at
>> said feature all day, every day when they are working on other people's
>> code, or are they just conforming because so many people are asking for a
>> feature, and they feel a desire to give the people what they ask for,
>> without considering the fact that the majority doesn't always consider the
>> implications of what they ask for?
>
>
> That has been asked a bunch of times by people opposing generics - the
> last time is was roughly two weeks ago and caused a discussion that spanned
> 187 messages over two threads
> https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo
> https://groups.google.com/g/golang-nuts/c/bj6kMQBTqUY
>
> So, the answer is: Yes. This is a feature wanted by the original designers
> of Go and there is evidence of that from long before Go was open sourced.
>
>
>> What I mean is to just give us an omnipotent "any" builtin type and to
>> make those special case functions that get extra attention by the runtime.
>>
>> func sort(a, b any){
>> if a < b{
>> lots of pre defined magic happens
>> }
>>
>
> If that was a solution to the kind of problems generics solve, we would
> already be using it. `type any = interface{}` is easy to write. But it's
> not - it a) doesn't express the constraints that both types have to be the
> same, b) doesn't express the constraint that this type is the same of the
> slice passed to Sort (I assume you meant to call your function less) and c)
> doesn't allow you to express constraints on such types that *aren't* "it
> can be anything".
>
> I think it isn't too much to ask to at least try and understand *what*
> people want from generics, even if you don't want them. Because trust me,
> it feels just as bad to have people ruin your language, as it feels to have
> people pretend to be deaf about what you actually want and repeatedly try
> to push the same non-solution unto you.
>
> The current proposals suck
>
>
> If you think it sucks, try and help to make it better. "It sucks" is not
> actionable feedback - it doesn't provide any information about what your
> specific problems are and how we can improve the proposal to work better
> for you.
>
>
>> The fact that you keep blogging essentially "hey guys were about to put
>> in generics... are you absolutely sure. because we aren't and once we
>> do were kind of stuck with it...?"
>>
>
> This is a blatant misquote.
>
>
>>
>> The answer is simply biological.
>>
>> If you don't want to then don't. But if you do then put it in already.
>>
>> --
>> 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/6a35c345-1686-4368-a5a8-dcacaa66d717n%40googlegroups.com
>> 
>> .
>>
> --
> 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/CAEkBMfF5D9G0M8OL1TQm9orR6%3D_Ear9mMw-3BesTG%3DVYRjt44g%40mail.gmail.com
> 
> .
>

-- 
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 

Re: [go-nuts] instead of generics, why cant we just implement an "any" builtin?

['Axel Wagner' via golang-nuts]

Hi,

On Tue, Jan 19, 2021 at 6:47 AM mortdeus  wrote:

> The more I look at the proposed generic syntax the more I feel like a
> texan fearing the californian relocation to my state. In other words I am
> feeling like Go had something awesome and extremely conservative going on
> in terms of syntax and because people from other super convoluted languages
> are coming over (which their leaving should say a lot about their said
> language) and they don't have their one "to die for" feature from their old
> language they are expecting us to conform.
>

You should keep in mind, then, that the generics design is driven by a) one
of the original designers of Go and b) one of the first people to join the
Go project after those original designers (long before the language was
open source).

So, if that analogy is apt, then only because Texans appropriated their
land from Native Americans and have no right to feel entitled to it.

The reality I want to ask is whether any of the designers of the language
> actually want this feature to the point that they want to be looking at
> said feature all day, every day when they are working on other people's
> code, or are they just conforming because so many people are asking for a
> feature, and they feel a desire to give the people what they ask for,
> without considering the fact that the majority doesn't always consider the
> implications of what they ask for?


That has been asked a bunch of times by people opposing generics - the last
time is was roughly two weeks ago and caused a discussion that spanned 187
messages over two threads
https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo
https://groups.google.com/g/golang-nuts/c/bj6kMQBTqUY

So, the answer is: Yes. This is a feature wanted by the original designers
of Go and there is evidence of that from long before Go was open sourced.


> What I mean is to just give us an omnipotent "any" builtin type and to
> make those special case functions that get extra attention by the runtime.
>
> func sort(a, b any){
> if a < b{
> lots of pre defined magic happens
> }
>

If that was a solution to the kind of problems generics solve, we would
already be using it. `type any = interface{}` is easy to write. But it's
not - it a) doesn't express the constraints that both types have to be the
same, b) doesn't express the constraint that this type is the same of the
slice passed to Sort (I assume you meant to call your function less) and c)
doesn't allow you to express constraints on such types that *aren't* "it
can be anything".

I think it isn't too much to ask to at least try and understand *what*
people want from generics, even if you don't want them. Because trust me,
it feels just as bad to have people ruin your language, as it feels to have
people pretend to be deaf about what you actually want and repeatedly try
to push the same non-solution unto you.

The current proposals suck


If you think it sucks, try and help to make it better. "It sucks" is not
actionable feedback - it doesn't provide any information about what your
specific problems are and how we can improve the proposal to work better
for you.


> The fact that you keep blogging essentially "hey guys were about to put in
> generics... are you absolutely sure. because we aren't and once we do
> were kind of stuck with it...?"
>

This is a blatant misquote.


>
> The answer is simply biological.
>
> If you don't want to then don't. But if you do then put it in already.
>
> --
> 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/6a35c345-1686-4368-a5a8-dcacaa66d717n%40googlegroups.com
> 
> .
>

-- 
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/CAEkBMfF5D9G0M8OL1TQm9orR6%3D_Ear9mMw-3BesTG%3DVYRjt44g%40mail.gmail.com.