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, <axel.wagner...@googlemail.com> wrote: > On Tue, Jan 19, 2021 at 12:19 PM Artur Vianna <lordhowen...@gmail.com> > wrote: > >> if you're trying to compare "a<b", the compiler (and/or go vet) will >> 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 > <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* (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 <mortd...@gmail.com> 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 >>>> <https://groups.google.com/d/msgid/golang-nuts/6a35c345-1686-4368-a5a8-dcacaa66d717n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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 >>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfF5D9G0M8OL1TQm9orR6%3D_Ear9mMw-3BesTG%3DVYRjt44g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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/CAE%3DAWBVgwGecka8cuiCqo85grwXWhv_fCXZC681aY7gYRrsT3Q%40mail.gmail.com.
