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

300 views
Skip to first unread message

Axel Wagner

unread,
Jan 19, 2021, 2:41:05 AM1/19/21
to mortdeus, golang-nuts
Hi,

On Tue, Jan 19, 2021 at 6:47 AM mortdeus <mort...@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

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

Artur Vianna

unread,
Jan 19, 2021, 6:20:19 AM1/19/21
to Axel Wagner, mortdeus, golang-nuts
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<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.

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.

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 (?).

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfF5D9G0M8OL1TQm9orR6%3D_Ear9mMw-3BesTG%3DVYRjt44g%40mail.gmail.com.

Kevin Chadwick

unread,
Jan 19, 2021, 6:30:37 AM1/19/21
to golang-nuts
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) {
}

Axel Wagner

unread,
Jan 19, 2021, 6:44:37 AM1/19/21
to Artur Vianna, mortdeus, golang-nuts
On Tue, Jan 19, 2021 at 12:19 PM Artur Vianna <lordho...@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, 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`.

Kevin Chadwick

unread,
Jan 19, 2021, 6:50:56 AM1/19/21
to golang-nuts
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]

Artur Vianna

unread,
Jan 19, 2021, 6:58:58 AM1/19/21
to Axel Wagner, mortdeus, golang-nuts
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"

Axel Wagner

unread,
Jan 19, 2021, 7:21:57 AM1/19/21
to Kevin Chadwick, 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.

--
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...@googlegroups.com.

Kevin Chadwick

unread,
Jan 19, 2021, 7:36:49 AM1/19/21
to golang-nuts
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.

Artur Vianna

unread,
Jan 19, 2021, 7:40:05 AM1/19/21
to Axel Wagner, Kevin Chadwick, golang-nuts
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGv8q3c8tXZha%2BVg1mO46WZqi_RTub%2BBGWT6OgrmPk7RA%40mail.gmail.com.

Axel Wagner

unread,
Jan 19, 2021, 8:41:50 AM1/19/21
to Kevin Chadwick, golang-nuts
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...@googlegroups.com.

Kevin Chadwick

unread,
Jan 19, 2021, 9:39:25 AM1/19/21
to golang-nuts
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.

Axel Wagner

unread,
Jan 19, 2021, 10:33:10 AM1/19/21
to Kevin Chadwick, golang-nuts
On Tue, Jan 19, 2021 at 3:39 PM Kevin Chadwick <m8il...@gmail.com> 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...@googlegroups.com.

Kevin Chadwick

unread,
Jan 19, 2021, 11:16:13 AM1/19/21
to golang-nuts
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).

Axel Wagner

unread,
Jan 19, 2021, 11:53:48 AM1/19/21
to Kevin Chadwick, golang-nuts
On Tue, Jan 19, 2021 at 5:16 PM Kevin Chadwick <m8il...@gmail.com> 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...@googlegroups.com.

Kevin Chadwick

unread,
Jan 19, 2021, 12:08:55 PM1/19/21
to golang-nuts
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?

Axel Wagner

unread,
Jan 19, 2021, 1:03:33 PM1/19/21
to Kevin Chadwick, golang-nuts
On Tue, Jan 19, 2021 at 6:08 PM Kevin Chadwick <m8il...@gmail.com> 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...@googlegroups.com.

Kevin Chadwick

unread,
Jan 19, 2021, 1:22:40 PM1/19/21
to golang-nuts

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

Carla Pfaff

unread,
Jan 19, 2021, 2:31:52 PM1/19/21
to 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

Kevin Chadwick

unread,
Jan 19, 2021, 3:01:51 PM1/19/21
to golang-nuts

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

I was inquiring about the possibility of no identifiers or abstraction but simply like Gos non generic functions (possibly reversed if needed). Using type OR type.

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

firstInput[0]
firstInput[[]byte]
}

Axel Wagner

unread,
Jan 19, 2021, 3:14:55 PM1/19/21
to Kevin Chadwick, golang-nuts
How would you express the equivalent of

func Min[T constraints.Ordered](a []T) T {
    min := a[0]
    for _, v := range a[1:] {
        if v < min {
            min = v
        }
    }
    return min
}

using this syntax? More generally, it is probably useful to go through the examples from the design draft and check if they can be clearly expressed using your suggested syntax.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/17BEE437-A5BB-4152-8215-B3F27A7265C1%40gmail.com.

Dan Kortschak

unread,
Jan 19, 2021, 3:22:43 PM1/19/21
to golan...@googlegroups.com
On Tue, 2021-01-19 at 20:01 +0000, Kevin Chadwick wrote:
> I was inquiring about the possibility of no identifiers or
> abstraction but simply like Gos non generic functions (possibly
> reversed if needed). Using type OR type.
>
> func (String | []byte firstInput, myType | publicKey
> secondInput) {
>
> firstInput[0]
> firstInput[[]byte]
> }


How does this encode the desire that parameter types match?


Kevin Chadwick

unread,
Jan 19, 2021, 4:09:36 PM1/19/21
to golan...@googlegroups.com
These are the parameters. dynamic var firstInput must be a String or byte slice.

Ian Lance Taylor

unread,
Jan 19, 2021, 4:09:43 PM1/19/21
to Kevin Chadwick, golang-nuts
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

Levieux Michel

unread,
Jan 19, 2021, 4:14:35 PM1/19/21
to Kevin Chadwick, golang-nuts
I think the question was: "given your proposal here, I can write func (string | []byte in1, string | []byte in2) which enforces that in1 and in2 must be either of type string or type []byte, but how do I tell the compiler that in1 and in2 must be of the *same type* (whether it is string or []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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/F183269A-E743-4069-90C3-0357F5C6D36D%40gmail.com.

Dan Kortschak

unread,
Jan 19, 2021, 4:20:29 PM1/19/21
to golan...@googlegroups.com
Yeah, that doesn't answer the question.

How do you make sure that types match where you have more than one
parameter where the types must match?

func find(s, pattern string | []byte) (string | []byte)

If find is looking for pattern in s and then returning it, how do you
indicate to the compiler that typeof(s) == typeof(pattern) and how do
you indicate what the return type is?


Kevin Chadwick

unread,
Jan 19, 2021, 5:45:57 PM1/19/21
to golan...@googlegroups.com
On January 19, 2021 9:13:55 PM UTC, Levieux Michel <mlevi...@gmail.com> wrote:
>I think the question was: "given your proposal here, I can write func
>(string | []byte in1, string | []byte in2) which enforces that in1 and
>in2
>must be either of type string or type []byte, but how do I tell the
>compiler that in1 and in2 must be of the *same type* (whether it is
>string
>or []byte) ? "
>

You could always use a well placed &. That isn't the point. 😉

Kevin Chadwick

unread,
Jan 19, 2021, 5:54:04 PM1/19/21
to golan...@googlegroups.com

>>string
>>or []byte) ? "
>>
>
>You could always use a well placed &. That isn't the point. 😉

Or perhaps group with {} like Darts optional parameters. Again though, not the point.

Dan Kortschak

unread,
Jan 19, 2021, 5:54:42 PM1/19/21
to golan...@googlegroups.com
On Tue, 2021-01-19 at 22:44 +0000, Kevin Chadwick wrote:
> On January
19, 2021 9:13:55 PM UTC, Levieux Michel <
> mlevi...@gmail.com> wrote:
> > I think the question was: "given your proposal here, I can write
> >
func
> > (string | []byte in1, string | []byte in2) which enforces that
in1
> > and
> > in2
> > must be either of type string or type []byte, but
how do I tell the
> > compiler that in1 and in2 must be of the *same
type* (whether it is
> > string
> > or []byte) ? "
> >
>
> You could
always use a well placed &. That isn't the point. 😉

What? How does that help?


Axel Wagner

unread,
Jan 19, 2021, 6:04:33 PM1/19/21
to Kevin Chadwick, golang-nuts
People (including me) do not understand your suggestion. They are asking question in an attempt to change that. If you want your suggestion to receive consideration, it would help if you could answer those questions. Write down the actual proposed syntax.

Better yet would be to write down an actual description of how the syntax would be defined could be parsed and what the semantics are, that are ascribed to it.

Again, this is in your interest - if you want people to consider your suggestion (or help you refine it into a workable solution), they first need to understand it.
 

--
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...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages