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

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 hav

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

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 prop

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

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

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

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 parame

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

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 c

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

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 ca

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

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 pr

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

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 lim

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

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

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

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

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

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

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

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

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

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

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

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

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

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 exp

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

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 conf

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

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 th

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

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 relo

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

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

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

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 ar