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/CAEkBMfEig0c7nzwxRvnN%3DfXUCqQEsRutF4L_%2BwRqVczfhbdF5g%40mail.gmail.com.
