Re: [go-nuts] Go Generics using interfaces - alternative take

On Tue, Jun 16, 2020 at 1:54 PM Arnaud Delobelle wrote: > > I noticed today the blog post about the revised Generics proposal. What got > me excited is this extract at the start: > > The biggest change is that we are dropping the idea of contracts. The > difference between contracts and

Re: [go-nuts] [generics] Type lists should be usable in any interface

On Tue, Jun 16, 2020 at 9:54 PM Bakul Shah wrote: > > Seems to me that perhaps 'ordered' should also be *predeclared*. > What happens if/when a big int type is added in future? Or > decimal or big floats. "The Expression Problem" comes to mind :-) Adding new predeclared types is sure to be rare.

Re: [go-nuts] [generics] Type lists should be usable in any interface

On Jun 16, 2020, at 7:06 PM, Brandon Dyck wrote: > > I find it a little strange that an interface with a type list can only be > used as a constraint, and not as the type of a variable or parameter, despite > it using basically the same syntax as a normal interface. Is this difference >

Re: [go-nuts] Re: [generics] Type lists should be usable in any interface

On Tue, Jun 16, 2020 at 9:04 PM Xie Zhenye wrote: > > I agree. constraint is different from normal interface. It's better to use > type SomeConstraint constraint {} than type SomeConstraint interface {} That is an option, but then we would have two different concepts, constraints and

Re: [go-nuts] [generics] Maybe possible to use <> instead of () as type parameter and

On Tue, Jun 16, 2020 at 9:02 PM Xie Zhenye wrote: > > In the draft, it says: > "Why not use the syntax F like C++ and Java? > When parsing code within a function, such as v := F, at the point of > seeing the < it's ambiguous whether we are seeing a type instantiation or an > expression using

Re: [go-nuts] [generics] Some ideas

On Tue, Jun 16, 2020 at 8:12 PM Pee Jai wrote: > > I read the proposal and am very impressed by it. I have 3 concerns however. > > 1. `F(type T)(p T) { ... }` > > To me, having 2 or 3 sets of parentheses is very weird. All mainstream > programming languages have only 1 set of parentheses for the

[go-nuts] Re: [generics] Type lists should be usable in any interface

I agree. constraint is different from normal interface. It's better to use type SomeConstraint constraint {} than type SomeConstraint interface {} On Wednesday, June 17, 2020 at 11:12:24 AM UTC+8 Brandon Dyck wrote: > I find it a little strange that an interface with a type list can only be

[go-nuts] [generics] Maybe possible to use <> instead of () as type parameter and

In the draft, it says: "Why not use the syntax F like C++ and Java? When parsing code within a function, such as v := F, at the point of seeing the < it's ambiguous whether we are seeing a type instantiation or an expression using the < operator. Resolving that requires effectively unbounded

Re: [go-nuts] Generics: More on parens

On Tue, Jun 16, 2020 at 8:31 PM Aaron Cannon wrote: > > I, like many others, am not fond of all the parenthesis, particularly at call > sites. I think at definition sites, it's not so bad. It seems like the only > objection to < and > are the complexity it adds for parsing. It also seems >

Re: [go-nuts] [generics] Type lists should be usable in any interface

On Tue, Jun 16, 2020 at 8:12 PM Brandon Dyck wrote: > > I find it a little strange that an interface with a type list can only be > used as a constraint, and not as the type of a variable or parameter, despite > it using basically the same syntax as a normal interface. Is this difference >

[go-nuts] Generics: More on parens

I, like many others, am not fond of all the parenthesis, particularly at call sites. I think at definition sites, it's not so bad. It seems like the only objection to < and > are the complexity it adds for parsing. It also seems like the only place it adds ambiguity is at call or enstantiation

[go-nuts] [generics] Some ideas

I read the proposal and am very impressed by it. I have 3 concerns however. 1. `F(type T)(p T) { ... }` To me, having 2 or 3 sets of parentheses is very weird. All mainstream programming languages have only 1 set of parentheses for the function's arguments. I've never seen 2 before. I know the

[go-nuts] [generics] Type lists should be usable in any interface

I find it a little strange that an interface with a type list can only be used as a constraint, and not as the type of a variable or parameter, despite it using basically the same syntax as a normal interface. Is this difference between constraints and other interfaces a property of the type

[go-nuts] subscribe

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

Re: [go-nuts] [generics] Generic functions calls little confusing to readers

On Tue, Jun 16, 2020 at 2:54 PM Alexander Morozov wrote: > > For example consider this example https://play.golang.org/p/rfccpBoFIJN > There is no generics involved, but for person reading the code there will be > additional cognitive load to recognize that it's returned closure call and > not

Re: [go-nuts] [generics] another parsing ambiguity

On Tue, Jun 16, 2020 at 4:49 PM Ben Kraft wrote: > > Consider the following code (playground): > > type R(type T) struct{} > func F(type T)() { > _ = func() R(T) { return R(T){} } > } > > That is, we have some parameterized type R(T), and a function literal which > returns that type R(T).

[go-nuts] [generics] another parsing ambiguity

Consider the following code (playground ): type R(type T) struct{} func F(type T)() { _ = func() R(T) { return R(T){} } } That is, we have some parameterized type R(T), and a function literal which returns that type R(T). (This is simplified

[go-nuts] Re: [generics] Generic functions calls little confusing to readers

Interesting find, I would expect type parameter declarations to be limited to interfaces. On Tuesday, June 16, 2020 at 2:54:02 PM UTC-7, Alexander Morozov wrote: > > For example consider this example https://play.golang.org/p/rfccpBoFIJN > There is no generics involved, but for person reading

Re: [go-nuts] Re: pure-go implementation of sqlite

This is at https://modernc.org/sqlite now, along with the rest of Jan's amazing things, https://gitlab.com/cznic. On Tue, 2020-06-16 at 12:27 -0700, Mandolyte wrote: > SQLite3 support is the stated goal of > https://github.com/elliotchance/c2go > > Also, I believe I tested this one a long time

[go-nuts] [generics] Generic functions calls little confusing to readers

For example consider this example https://play.golang.org/p/rfccpBoFIJN There is no generics involved, but for person reading the code there will be additional cognitive load to recognize that it's returned closure call and not generic function call. I wonder how could we avoid this confusion

Re: [go-nuts] Black Lives Matter question

Sorry, but this thread is definitely off-topic here. I'm going to lock this conversation. Best, Russ On Tue, Jun 16, 2020 at 4:53 PM Jon Perryman wrote: > Sorry for this being a little off topic but unlike the media which thinks > with the heart, programmers tend to think with their head. I

[go-nuts] Go Generics using interfaces - alternative take

Hi everyone, I noticed today the blog post about the revised Generics proposal. What got me excited is this extract at the start: *The biggest change is that we are dropping the idea of contracts. The difference between contracts and interface types was confusing, so we’re eliminating that

[go-nuts] Black Lives Matter question

Sorry for this being a little off topic but unlike the media which thinks with the heart, programmers tend to think with their head. I want to believe in the idea of "systemic police racism" over blaming all police for a few bad cops. Since this group supports the idea of "systemic police racism",

[go-nuts] Re: pure-go implementation of sqlite

SQLite3 support is the stated goal of https://github.com/elliotchance/c2go Also, I believe I tested this one a long time ago... but have lost track of it after they moved away from Github: https://github.com/cznic/sqlite On Monday, June 15, 2020 at 12:57:54 PM UTC-4, Douglas Manley wrote: > >

[go-nuts] [security] Vulnerability in golang.org/x/text/encoding/unicode

Hello gophers, Version v0.3.3 of golang.org/x/text fixes a vulnerability in the golang.org/x/text/encoding/unicode package which could lead to the UTF-16 decoder entering an infinite loop, causing the program to crash or run out of memory. An attacker could provide a single byte to a UTF16

[go-nuts] Re: Unable to send continuous event logs using template

text/event-stream is not text/html. text/event-stream is exactly that: a stream of (plain text) messages. If you point a browser directly at this URL, it will render the stream as plain text. If you want pretty rendering, what you need is a wrapper HTML page which contains some Javascript to

[go-nuts] Re: Build Issues on Ubuntu

We have a winner! Lots of attempts to read /usr/local/go/src/syscall, which is very read only And not any go install it should be using, looks like GOTOOL was pointing at the wrong place(the default install, not any of the ones I did). No idea who is setting that up, but I can soon fix that.

Re: [go-nuts] Re: political fundraising on golang.org!

This thread is visibly not working. I would like to ask everyone to do their very best to let this thread drop. Please do not try to get the last word. If you absolutely must continue, I strongly encourage you to take it to private e-mail, off the list. This applies to everyone, regardless of

Re: [go-nuts] Re: political fundraising on golang.org!

On 6/16/20 09:04, 'Thomas Bushnell, BSG' via golang-nuts wrote: On Tue, Jun 16, 2020 at 11:51 AM 'K Richard Pixley' via golang-nuts mailto:golang-nuts@googlegroups.com>> wrote: I do not agree with the Rust team.  I would prefer to make my technology decisions based on technological

Re: [go-nuts] Re: political fundraising on golang.org!

On Tue, Jun 16, 2020 at 11:51 AM 'K Richard Pixley' via golang-nuts < golang-nuts@googlegroups.com> wrote: > I do not agree with the Rust team. I would prefer to make my technology > decisions based on technological criterion. But if you force me to make > that decision based on your religion,

Re: [go-nuts] Re: political fundraising on golang.org!

On Tuesday, June 16, 2020 at 11:52:10 AM UTC-4, K Richard Pixley wrote: > > There is agreement on the code of conduct. There is not agreement on the > banner. IMO, the banner is out of line with the goals of this group and > with the code of conduct. It's inappropriate. It needs to be

[go-nuts] Unable to send continuous event logs using template

I'm little new with golang and first time working with html templates. I need to send continuous event logs(server sent events) to the client side for which I am using flusher. I'm facing 2 different issues here: 1. The moment I add these 3 lines --

[go-nuts] Golang Developers in Hyderabad

If you have experience in Golang and want to work with IBM then lets connect ... I have a good opportunity in my team. -- 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

Re: [go-nuts] Re: political fundraising on golang.org!

On 6/16/20 5:00 AM, Russ Cox wrote: ...I will quote from the Code of Conduct here – “regardless of gender identity and expression, sexual orientation, disabilities, neurodiversity, physical appearance, body size, ethnicity, nationality, race, age, religion, or similar personal

Re: [go-nuts] Re: political fundraising on golang.org!

On Tue, Jun 16, 2020 at 10:41 AM Space A. wrote: > > Are you saying you don't care about the rest of the World? This > "situation" does not affect in any way many many gophers which have to deal > with much more serious problems than you could imagine, on a daily basis. > There are a lot of

[go-nuts] Re: political fundraising on golang.org!

Raise your hand if you think black lives don't matter? Raise your hand if you think "[providing] legal representation to prisoners who may have been wrongly convicted of crimes, poor prisoners without effective representation, and others who may have been denied a fair trial." is a bad thing?

Re: [go-nuts] Re: political fundraising on golang.org!

> To people who object to the banner as too focused on the United States: > Google and Go both started here, nearly all of the Go team is here, a > substantial number of Go community members live here, and many others > travel here for conferences or other reasons. The situation here affects

Re: [go-nuts] Re: political fundraising on golang.org!

Hi everyone, I wanted to reply here to acknowledge the feedback on this thread. I hear those of you who are uncomfortable with the banner, and I appreciate the honest and mostly constructive discussion here. As the Rust team said well, tech is and will always be political, not in the sense of

Re: [go-nuts] pure-go implementation of sqlite

On 16 Jun 2020, at 12:35, a2800276 wrote: > Can you elaborate a little bit on the motivation? I've been using go-sqlite > on both amd64 and arm64 with absolutely no problem. The biggest obstacle for me (I'm not the topic-starter) is a loss of out-of-the-box cross-compilation. Can be ameliorated

Re: [go-nuts] Re: pure-go implementation of sqlite

> > is there (or is somebody working on) a pure-go implementation of sqlite ? > > or at least a subset of it, to be able to read sqlite files ? > > > > -s > > > > PS: I know about the (by now) canonical implementations > > (mattn/go-sqlite and others) but a completely go-based solution would

[go-nuts] Re: pure-go implementation of sqlite

> > is there (or is somebody working on) a pure-go implementation of sqlite ? > or at least a subset of it, to be able to read sqlite files ? > > -s > > PS: I know about the (by now) canonical implementations > (mattn/go-sqlite and others) but a completely go-based solution would >

[go-nuts] Re: Build Issues on Ubuntu

On Monday, 15 June 2020 21:59:21 UTC+1, Chris Hopkins wrote: > > The ubuntu default 1.14.4 > https://dl.google.com/go/go1.14.4.src.tar.gz > What about the 1.14.4 precompiled binary? https://dl.google.com/go/go1.14.4.linux-amd64.tar.gz I

Re: [go-nuts] Re: political fundraising on golang.org!

After all (I think this has been discussed already ), who is owner of the Golang Project ? Isn't this supposed to be an open source / community based project ? What about mine political ideas, can I put them also on golang's front page, since I am part of the community ? Where will we end up

Re: [go-nuts] Build Issues on Ubuntu

Yep, the asyncpreempt has definitly made it work.(But for how long Dun Dun Dun!!!) Humm, interesting. Thanks I can do some more investigation now. Kind Regards Chris On Monday, 15 June 2020 22:27:00 UTC+1, Ian Lance Taylor wrote: > > On Mon, Jun 15, 2020 at 1:59 PM Chris Hopkins >

Re: [go-nuts] Re: political fundraising on golang.org!

On 6/16/20 2:43 PM, Sam Whited wrote: So you're suggesting that because we can't help all people all of the time we should help no one at any time? That is a logical fallacy. Right now in this moment there are protests all over the world about a specific issue, so yes, a specific cause is being

Re: [go-nuts] Re: political fundraising on golang.org!

So you're suggesting that because we can't help all people all of the time we should help no one at any time? That is a logical fallacy. Right now in this moment there are protests all over the world about a specific issue, so yes, a specific cause is being supported because the time is right, and