Re: [go-nuts] Generics and parentheses

Very correct! At least from my perspective. On Thu, 23 Jul 2020 at 02:02 Russ Cox wrote: > So it sounds like everyone is in favor of the entire generics proposal and > all the semantics, and all we have left to hammer out is the bracket > characters? Do I have that right? > > Best, > Russ > > >

Re: [go-nuts] Re: Generics and parentheses

Thanks for the feedback Ian! I was drawing the idea mostly from Rust, which already does the same thing, but uses "::" instead of a dot and it works fine there, but sure, it has its drawbacks. st 22. 7. 2020 o 0:05 Ian Lance Taylor napísal(a): > On Tue, Jul 21, 2020 at 8:49 AM wrote: > > > > I

Re: [go-nuts] Generics and parentheses

I'd say a dot is necessary when instantiating a function call but unnecessary when instantiating a type because it's always syntactically clear when a type is required. ut 21. 7. 2020 o 18:51 napísal(a): > Using angle brackets is not a must for supporting generics, but it is the > common syntax

Re: [go-nuts] Re: Generics and parentheses

Angle brackets are only problematic in expressions in the bodies of functions when specializing a function or a type, right? They are not problematic in signatures and type definitions. What about using a dot when specializing in bodies? func zero() T { var z T return z }

Re: [go-nuts] A better io.Reader.Read signature?

Your proposed signature has a little problem and that is that when calling result, err := reader.Read(nil) the Read method doesn’t know how many bytes it should read. The incoming buffer parameter actually serves two purposes. First is to provide a place for storage. The second is to tell ho

Re: [go-nuts] VSCode

Why do you need to modify the .bashrc file? All I did was to install the Go extension and everything else proceeded either automatically or through a few dialog boxes. On Tue, 27 Aug 2019 at 14:40 Andreqx wrote: > I am trying to install VSCode to run with Go. I Need to modify the > /.bashrc file

Re: [go-nuts] Re: About the Google logo on the new Go website

Guys, why not keep the discussion to the point. Oracle is quite irrelevant here. The issue is the perception of Go among programmers. On Wed, Jul 17, 2019, 11:46 Wojciech S. Czarnecki wrote: > On Tue, 16 Jul 2019 23:06:41 -0700 > Michael Jones wrote: > > > In regards to Oracle, I was delighted

Re: [go-nuts] Re: About the Google logo on the new Go website

Okay, so just to explain why I started this topic and what exactly we are talking about. First of all, just to clear up any doubts, I have no problem with the logo. Google 100% deserves to be there. The thing that I'm talking about is this. Every once in a white, I come across a discussion that s

[go-nuts] About the Google logo on the new Go website

As you all know, the new, redesigned Go website has a Google logo in the bottom right corner. Someone opened an issue about this, worrying that with the logo, nobody will see Go as a community project: https://github.com/golang/go/issues/33021 The issue was promptly closed and locked by a Go team

Re: [go-nuts] Re: errors/wrap.go looks like it could be made into a more general monad package?

First of all, this is not at all what "monad" means. A monad is a way to express threading of values between computations. A result of one computation gets threaded as an input to the next one, and so on. Second, what would be the use-case of this other than errors? On Wed, Jul 3, 2019, 04:52 Ger

Re: [go-nuts] is there any type that cannot be sent on a channel?

Not sure where you read that. Anything can be sent on a channel. Even channels can be sent over channels. That's often used when one goroutine needs to reply to a message from another goroutine. ne 30. 6. 2019 o 18:31 Sathish VJ napísal(a): > I thought I read somewhere that functions cannot be s

Re: [go-nuts] Re: A proof-of-concept implementation of my generics proposal for Go

iked the original proposal, but using the > "type" keyword seems very natural. And I like the 80/20 constraints thing > with eq/ord/num. Good work -- I hope this gets turned into an official > proposal and debated. > > > > -Ben > > > > > > On Thursday, J

[go-nuts] A proof-of-concept implementation of my generics proposal for Go

Hey everybody! A few weeks ago, I posted about my proposal for generics in Go 2. You can find it here. Today, I finished a proof-of-concept implementation. It was a lot of fun and I learned a lot about the internals of Go. The

Re: [go-nuts] bogus "missing return at end of function"

Can you post a code (preferably a link to play.golang.org) that does this? I can't reproduce it myself. On Mon, Jun 10, 2019, 02:40 Marvin Renich wrote: > Is it already a known issue that a «for [true] { ... }» loop whose only > exit path is through return statements inside the loop (i.e. no br

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

Taylor napísal(a): > On Wed, Jun 5, 2019 at 3:02 PM Michal Strba wrote: > > > > Ian, have you had the time to evaluate the improvements to my proposal > (the original one in this thread)? I'd love to hear if it has some more > significat shortcomings and know what

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

ponding with "I haven't had the time yet" is completely understandable. Thanks On Wed, Jun 5, 2019, 22:18 Robert Engels wrote: > > > > > > > -Original Message- > >From: Randall O'Reilly > >Sent: Jun 5, 2019 2:33 PM > >To: Rober

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

> Again thank you for your work exploring this! > > Best regards >Marin > > On 03.06.19 15:49, Michal Strba wrote: > > 'const' could be fine too. I guess this is mostly a matter of personal > > preference. > > > > Regarding the array length syntax. It

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

plicit keyword qualifier, because - again - it's unambiguous in the > parameter context. Would you agree? > > Best regards >Martin > > On 03.06.19 14:20, Michal Strba wrote: > > Hi Martin. > > > > The proposal adds types as "values", but not re

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

as identifier, mostly for generators > and generated code. While nobody can claim to use 'type'. This would > make converting code so much easier, if this proposal is accepted. > > Just a though. Please tell me whether this would be possible. > > Thanks for your work, it&#x

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

Btw, as is demonstrated in the proposal, sorting can be solved by passing a comparator to the function: ```go func Sort(a []gen T, less func(T, T) bool) ``` This is actually a far more flexible way than sorting based on an operator or a `Less` method. Sorting based on an operator or `Less` limits

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

@Ian, I have been thinking and I’ve come up with a possible solution to yours and some other problems. I’d love to hear your thoughts on it. Note, that this is a very fresh idea. I’m addressing two problems here: 1. Inability to do Min/Max and other generic numeric functions. 2. The

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

Ian and David, thanks for the response! I personally don't consider MIn and Max to be so important, however, I understand if you do. I've added a new little part to the proposal that describes one possible way for them to be supported: Currently, the type-checker has to distinguish between three k

Re: [go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

ded, based on my history dealing with > unnecessary and avoidable 'cryptic C++, > my input is: Generics are a great idea EXCEPT when they allow use of > cryptic syntax > > On Thursday, May 30, 2019 at 12:29:03 PM UTC-4, Michal Strba wrote: >> >> Hi Gophers! :)

[go-nuts] Re: Go 2 generics counterproposal: giving up restricting types

ents that require lots of effort to >> understand. After looking at the link you provided my input, based on >> dealing with cryptic C++ is: Go should not allow cryptic syntax. >> > Generics are useful except when their syntax becomes cryptic > > >>

[go-nuts] Go 2 generics counterproposal: giving up restricting types

Hi Gophers! :) I've been thinking about generics in Go 2 ever since the original contracts proposal and few days ago, ideas finally clicked. One of the main things about this proposal is that it deliberately omits the ability to restrict the set of types a function can work with. This is a limi