Re: [go-nuts] GO111MODULE=off go get deprecated?

It's not quite what you're after, but FWIW the gohack command ( github.com/rogpeppe/gohack) knows enough to download arbitrary Go modules including the VCS checkout. You might find it useful, I guess. For example: % gohack get -vcs golang.org/x/mod creating golang.org/x/mod@v0.16.0

Re: [go-nuts] assert library with generics?

I'm biased because I had a big hand in designing the API, but I get a lot of pleasure from using this package: https://pkg.go.dev/github.com/go-quicktest/qt It does a lot more than just "equals" and "not equals" but it's still relatively small and low-dependency. And the error messages when

Re: [go-nuts] Type parameter embedded field

On Fri, 5 Jan 2024 at 05:58, 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Hi, > > I think the reason this has not happened is that it makes code using such > a type invalid, depending on the type-argument - in ways not captured by > the constraint. For example: > > type

Re: [go-nuts] [ANN] type-safe templates

This is very cool, thanks! On Sun, 10 Sept 2023 at 16:20, Jonathan Amsterdam wrote: > The latest version of github.com/jba/templatecheck[0] > supports templates that > cannot have type errors at execution time. > > Once you've parsed your template

Re: [go-nuts] Would it be possible to make this work in the future?

> We would have to have careful definitions of what kinds of code are permitted in a case with multiple types. ISTM that we already have such a careful definition with generics: given a case in a `switch x.(type)` statement of the form `T1, T2, ..., Tn`, where `x` is of type `S`, we could define

Re: [go-nuts] Interface embedding

On Tue, 29 Aug 2023 at 13:35, Remko Tronçon wrote: > The Google Cloud Go library contains the following code (See > https://github.com/googleapis/google-cloud-go/blob/38a040e213cc8af5b01b3afe422481493f54382f/datastore/client.go#L36 > ) > > // datastoreClient is a wrapper for the

Re: [go-nuts] Is it possible to switch on type T in a generic function?

If you're sure that T is an int or a string, then why not constrain it as such? https://go.dev/play/p/1kT6EacMHco You could go further and constrain it to allow any type with ordering defined: https://go.dev/play/p/il5koj1RPkh If you want to allow any kind of comparable key in your set, one

Re: [go-nuts] How is the relationship between package version and tag, and what is the formation mechanism?

Hi, This is documented in the Go module documentation here: https://go.dev/ref/mod#vcs-version cheers, rog. On Thu, 29 Sept 2022 at 18:29, 'Jinchang Hu' via golang-nuts < golang-nuts@googlegroups.com> wrote: > When we use go list -m dependencyName@Version to get the specific > information

Re: [go-nuts] Type switch on generic parameter

See https://github.com/golang/go/issues/45380 for a proposal for a language feature that would allow this. In the meantime, you can convert to any, and type switch on that: func Foo[T allowedTypes](arg T) { switch t := any(arg).(type) { case int64: ... On Fri, 12 Aug 2022, 00:40 'Matt

Re: [go-nuts] Preemptive interfaces in Go

One significant argument against preemptive interfaces is that you can't add a method to an interface type without breaking compatibility. Also, an interface is significantly less amenable to static analysis because it's not certain where a method call is implemented. One concern I have about

Re: [go-nuts] zero value for generic types?

On Wed, 20 Apr 2022 at 23:29, Arthur Comte wrote: > Actually, even with proper error handling, I still need to return a value. > In some functions I can just return a variable that was defined in the > function, but that is not always available. In those cases, the only > solution I've found is

Re: [go-nuts] Any recipe to stop a goroutine of a function other than of a channel?

en throw out an error. > But I am surprised at why golang still has not provided a general feature > on that. > > Zhaoxun > > On Sat, Apr 16, 2022 at 10:14 PM roger peppe wrote: > >> Most network functions provide a way to provide a timeout or cancellation >> ex

Re: [go-nuts] Any recipe to stop a goroutine of a function other than of a channel?

Most network functions provide a way to provide a timeout or cancellation explicitly. Listen is one such: see this method - if the context that it's passed is cancelled, the Listen call will return. https://pkg.go.dev/net#ListenConfig.Listen The most general way to stop waiting on timeout or

Re: [go-nuts] generics: parametric types unmarshaling

On Thu, 14 Apr 2022, 09:50 'Sebastien Binet' via golang-nuts, < golang-nuts@googlegroups.com> wrote: > hi there, > > I am playing a bit with generics. > I am trying to implement a parametrized "Read" function that unmarshals > bytes into some type value that implements an interface: > > type T1

Re: [go-nuts] Re: New edition of the Go Programming Language comming soon ?

On Tue, 15 Mar 2022 at 04:58, Rob Muhlestein wrote: > The essential issue is that there are a number of resources for people > "with prior programming experience" and literally none for people learning > Go as a first language. > It does have significant omissions (all programs in the book can

Re: [go-nuts] Improving on unit test styles

On Fri, 25 Feb 2022, 18:46 'Markus Zimmermann' via golang-nuts, < golang-nuts@googlegroups.com> wrote: > Hi Gophers! > > We were unhappy with the common unit test styles and we think we found a > style that has clear advantages. An in-depth comparison can be found here >

Re: [go-nuts] No time.Duration#UnmarshalText; is there a good reason?

On Wed, 19 Jan 2022 at 04:19, Ian Lance Taylor wrote: > On Mon, Jan 17, 2022 at 9:53 PM Corin Lawson > wrote: > > > > It seems obvious (to me) that the encoding.TextUnmarshaler interface > could be implemented for time.Duration (it is implemented for time.Time, > afterall). > > > > The fact

Re: [go-nuts] Limits of type parameter inference in function calls

See https://github.com/golang/go/issues/41176. On Sun, 7 Nov 2021, 12:47 Florian Weimer, wrote: > * Axel Wagner: > > > One way to fix this is to change the signatures to > > > > func Contains[I Iterator[T], T comparable](c I, value T) bool > > func Contains2[I Iterator[T], T comparable](value

Re: [go-nuts] testing if strconv.Quote() would do change a string, without calling it

On Thu, 14 Oct 2021 at 04:58, 'Tim Hockin' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Thanks for confirming. I wrote that function and erased a good bit of the > overhead. > > bytes.Buffer for the no-escapes path and strconv.Quote otherwise. > Could you not use strconv.AppendQuote

Re: [go-nuts] Will the generics support be enabled by default in Go 1.18?

On Tue, 12 Oct 2021 at 01:42, Ian Lance Taylor wrote: > On Mon, Oct 11, 2021 at 2:36 AM peter.m...@gmail.com > wrote: > > > > I'm curious, was any consideration given to hiding generics behind a > flag in 1.18? The idea being it's such a complex feature that one could > imagine a backwards

Re: [go-nuts] Can generics help me make my library safer?

solution) >>> >>> Even with static checking there is no way to ensure that tablex has the >>> needed fields. Even if you could check this at compile time - it might be >>> different at runtime. >>> >>> I don’t think the juice is worth the squeeze. &

Re: [go-nuts] Can generics help me make my library safer?

On Wed, 6 Oct 2021 at 12:44, Robert Engels wrote: > Personally, I think this is overkill (the entire concept not the rog > solution) > I tend to agree, but the bait was too irresistible :) I do think that using reflection in combination with generics the way I showed can be really useful. This

Re: [go-nuts] Can generics help me make my library safer?

On Wed, 6 Oct 2021 at 09:21, mi...@ubo.ro wrote: > Hi Ian , > > I've modified the example towards a more specific use case. The main idea > in the example below is to make code related to database operations(i.e > SELECT queries) safer and easier to read. A kind of > json.Unmarshal/Marshal

Re: [go-nuts] Idea extending xerror.As

In some ways, the existing API is arguably more ergonomic than the originally proposed generic version, as it's possible to use `errors.As` in a switch statement (eg to test several possible types of error) which isn't possible with the multi-return `As` variant. A minor variant of the existing

Re: [go-nuts] Still "missing" priority or ordered select in go?

On Thu, 6 May 2021 at 14:41, 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > PS: And I'm not saying there is no argument. Maybe "select is not atomic" > is such an argument. But if there is an argument and/or if this is that > argument, I don't fully understand it myself. >

Re: [go-nuts] Still "missing" priority or ordered select in go?

On Mon, 3 May 2021 at 20:24, Øyvind Teig wrote: > I see that, which is great. But I still don't understand why > https://go2goplay.golang.org/p/S_5WFkpqMP_H (By *rog*, 29Apr2021 > 23:52:05) seems not to print "Client 2". > That's because to try to emphasise the arbitrariness of the producers

Re: [go-nuts] Still "missing" priority or ordered select in go?

On Thu, 29 Apr 2021, 20:05 Øyvind Teig, wrote: > torsdag 29. april 2021 kl. 20:22:32 UTC+2 skrev rog: > >> I agree with Axel's take here. It seems, Øyvind, that you are concerned >> more with principle than practice here. Can you give an example of a real >> world case where you think that this

Re: [go-nuts] Still "missing" priority or ordered select in go?

I agree with Axel's take here. It seems, Øyvind, that you are concerned more with principle than practice here. Can you give an example of a real world case where you think that this might actually matter? On Thu, 29 Apr 2021, 15:44 'Axel Wagner' via golang-nuts, < golang-nuts@googlegroups.com>

Re: [go-nuts] Re: Modules... why it has to be so painfull?

On Fri, 9 Apr 2021, 16:37 'gonutz' via golang-nuts, < golang-nuts@googlegroups.com> wrote: > Justin Isreael said > > "Changes to ProjectB should be immediately available when compiling > ProjectA." > > which is not true when you simply insert a replace in your go.mod file. > > My current problem

Re: [go-nuts] Re: Update to generics proposal

On Mon, 5 Apr 2021, 21:58 yiyus, wrote: > A type and its underlying type support exactly the same operations > FWIW I don't believe that's the case. A type may have methods (each with at least one corresponding operation) that its underlying type does not. -- You received this message

Re: [go-nuts] Re: Update to generics proposal

On Sun, 4 Apr 2021 at 00:48, Eltjon Metko wrote: > I was fully expecting for floodgates of comments to open again but it > seems we have reached a point of maturity in the generics proposal. > The new proposal really makes the intent much clearer both on the exact vs > underlying type match

Re: [go-nuts] Finding error type for `errors.As` and `errors.Is`

On Wed, 31 Mar 2021 at 18:05, 'Michael Schaller' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Hi everyone, > > I often encounter deep error chains where errors are wrapped across > several Go packages and that makes it often hard to find a usable error > type to use with `errors.As`

Re: [go-nuts] How to wait for HTTP server to start?

I often call net.Listen directly before calling Serve in a goroutine. That way you can connect to the server's socket immediately even though the server might take a while to get around to serving the request. Look at how net/http/httptest does it. On Sat, 27 Mar 2021, 14:13 cpu...@gmail.com,

Re: [go-nuts] Orderly exit

On Tue, 23 Feb 2021 at 12:10, Kevin Chadwick wrote: > I only instigate panic manually for one thing. Perhaps that will change, > but I doubt it. > > If I want to send out or write a log to disk then I will call panic rather > than os.exit, upon a log.fatal scenario. Think buffered go routine

Re: [go-nuts] Re: Few questions regarding Generics

On Mon, 22 Feb 2021 at 18:07, Khosrow Afroozeh wrote: > aha, thanks for your help! One problem down. > > The error message is pretty cryptic though, I’d assumed the type inference > would automatically take care of it, or complain about instantiation. > I think it should probably work, but

Re: [go-nuts] Error handling

On Sat, 20 Feb 2021, 16:31 L Godioleskky, wrote: > Rust lang, very early in its evolution, saw the need to create its > operator '?' to more efficiently manage error handling. But the guardians > of Go lang have resisted any changes to its clumsy method of error handling > despite it being a

Re: [go-nuts] big.Float.Cmp does not work as expected

Thanks for bringing this up. It surprised me too until I realised what was going on. The issue here is about the default precision that you're getting for those big.Float values. When you use big.NewFloat, the precision you get is exactly the same as that of a base64 float (53 bits). When you use

Re: [go-nuts] Possible to make base64 pick the decode encoding automatically?

In case you find it helpful, here's a clone of the base64 command that I wrote in Go. I did it precisely because I wanted to be able to decode any encoding scheme interchangeably. https://github.com/rogpeppe/misc/blob/master/cmd/base64/base64.go I agree that it might be useful to have some of

Re: [go-nuts] Re: Virtual time for testing

On Sat, 30 Jan 2021 at 20:12, Christian Worm Mortensen wrote: > Hi Mike, > > Thank you for your consideration. I think you exactly got the essence of > my question: How do I wait on all go routines to finish (or be blocked on > one or more channels) before advancing time. > This is an

Re: [go-nuts] Re: Interface arguments to generic functions

On Wed, 20 Jan 2021 at 11:04, Brian Candler wrote: > What do you make of this? > https://go2goplay.golang.org/p/gN-FK2kbYK5 > > Using interface values, it seems possible to bypass a declared constraint > that two arguments have the same type. > This code is misleading. By passing the value to

Re: [go-nuts] [ANN] github.com/jba/codec, a fast encoder for Go

On Wed, 20 Jan 2021 at 13:31, Jonathan Amsterdam wrote: > The encoding scheme is described briefly in the README[0] and the code[1]. > > To answer your two specific questions, interfaces are represented as a > pair (typeNumber, value) where typeNumber maps to a registered type. (Like > gob,

Re: [go-nuts] [ANN] github.com/jba/codec, a fast encoder for Go

This is interesting, thanks! Is there a full description of the encoding somewhere? (e.g. how are structs represented? what about interface values, etc? is the schema implicit or sent on the wire?) cheers, rog. On Tue, 19 Jan 2021 at 14:59, Jonathan Amsterdam wrote: > Uses code generation

Re: [go-nuts] Workaround for No parameterized methods in go generics draft

FWIW I think that one possible approach to allowing methods (and potentially function values) with type parameters might be to allow instantiating them only with a limited set of "shapes" of data (for example, only pointer-like types). Then I think there's the possibility that the method or

Re: [go-nuts] Workaround for No parameterized methods in go generics draft

On Wed, 13 Jan 2021 at 20:38, Marcus Manning wrote: > > Regarding the the section of No parameterized methods in go generics > draft: > > package p1 // S is a type with a parameterized method Identity. type S > struct{} // Identity is a simple identity method that works for any type. > func (S)

Re: [go-nuts] Generics and constraints question

You can do this with type-list interfaces: https://go2goplay.golang.org/p/wfHnVHOMcyK This is one of the harder parts of the proposal to understand IMHO, but perhaps it will become easier with familiarity. On Tue, 5 Jan 2021, 17:32 Brian Candler, wrote: > Question: how to make a generic

Re: [go-nuts] Generics - please provide real life problems

FWIW I'm certain that the lack of tuples in Go was a very deliberate decision - one of Go's more significant ancestors, Limbo, had tuples. Anonymous product types have their disadvantages too (you don't get to name the members, so code can end up significantly harder to understand), which I

Re: [go-nuts] Generics Error - How to fix?

On Fri, 1 Jan 2021, 17:49 da...@suarezhouse.net, wrote: > First of all -- awesome, thanks!!! > > Question 1: the need for the additional typeOf function you added at the > end, would that be needed in a future implementation or would that be > deduced in the existing reflect.TypeOf in the

Re: [go-nuts] Generics Error - How to fix?

You need to declare the type parameters in the method definitions too. Something like this works OK: https://go2goplay.golang.org/p/ZUAVncRrmZW cheers, rog. On Fri, 1 Jan 2021 at 15:06, da...@suarezhouse.net wrote: > I thought I read the generics doc well but.. :-) Help is appreciated:

Re: [go-nuts] Generics - please provide real life problems

Here's one real life example that I came across recently. I have a CRUD API that supports a bunch of different entity types. They all support a superset of the same operations. Each method represents a single HTTP call. If the generics proposal was implemented, I'd be able to define a common

Re: [go-nuts] How to set the "godebug" environment variable from the go file?

On Wed, 16 Dec 2020, 21:29 Ian Lance Taylor, wrote: > On Wed, Dec 16, 2020 at 8:49 AM Sean wrote: > > > > hi all, > > i have a project I have to work with CGo. I want to disable some > > controls as they are not good enough right now. > > It works when I write "set godebug=cgocheck=0" on

Re: [go-nuts] [generics] combining different instances of the same generic type

On Wed, 2 Dec 2020 at 09:15, roger peppe wrote: > Also your delayed blocks don't wait for the preceding set of futures to be >> exhausted before proceeding, I think they're all triggered once the initial >> set is completed > > > Each delayed block is triggered when

Re: [go-nuts] [generics] combining different instances of the same generic type

t)). It's > clearly not F[interface{}], for lack of better notation, I'll call it F[*]. > > On Wed, 2 Dec 2020 at 10:07, roger peppe wrote: > >> And again (no need to make a cancelable context) >> https://go2goplay.golang.org/p/3UFUaXijuX9 >> >> On Tue, 1 Dec 20

Re: [go-nuts] [generics] combining different instances of the same generic type

And again (no need to make a cancelable context) https://go2goplay.golang.org/p/3UFUaXijuX9 On Tue, 1 Dec 2020 at 22:59, roger peppe wrote: > Slightly simpler again: https://go2goplay.golang.org/p/mKdishv4nhT > > On Tue, 1 Dec 2020 at 18:44, roger peppe wrote: > >> I'm

Re: [go-nuts] [generics] combining different instances of the same generic type

Slightly simpler again: https://go2goplay.golang.org/p/mKdishv4nhT On Tue, 1 Dec 2020 at 18:44, roger peppe wrote: > I'm having difficulty understanding exactly what your code is trying to do > (and why), and that makes it hard to understand what > generic solution might be ap

Re: [go-nuts] [generics] combining different instances of the same generic type

I'm having difficulty understanding exactly what your code is trying to do (and why), and that makes it hard to understand what generic solution might be appropriate. However, here's one alternative implementation that doesn't seem to run into the same kind of issues that you did. It changes the

Re: [go-nuts] Go modules replace statements referencing legacy codebases

I don't quite understand why you're using replace directives here rather than just declaring the pseudo-version as a requirement. Why wouldn't that work? On Fri, 6 Nov 2020, 14:19 Jim Minter, wrote: > Hi, > > Using Go 1.14, I'm working on a parent codebase which, in its go.mod > file, has a

Re: [go-nuts] Table driven tests and error/output testing

It looks like you're testing a top level command. You might want to consider using the testscript package, which provides a very concise way of end-to-end testing this kind of thing. e.g. mycommand -h cmp stdout expect-stdout -- expect-stdout -- Expected output See

Re: [go-nuts] global goroutine data / thread local storage?

On Sat, 26 Sep 2020, 02:36 Alex Besogonov, wrote: > On Friday, September 25, 2020 at 4:43:45 PM UTC-7 Ian Lance Taylor wrote: > >> On Fri, Sep 25, 2020 at 10:35 AM Alex Besogonov >> wrote: >> > >> > Inheritable goroutine-locals would actually work just fine in Go. >> Moreover, Go actually has

Re: [go-nuts] Find n-th root of a big number

Relevant issue: https://golang.org/issue/14102 On Tue, 22 Sep 2020 at 08:54, Nasir Hussain wrote: > The Amazing Rob Pike :D > > On Tue, Sep 22, 2020 at 12:13 PM Rob Pike wrote: > >> I'm not going to debug you program for you - you'll learn more doing it >> yourself, but I glanced at it and

Re: [go-nuts] unit test for function which has goroutine

On Thu, 10 Sep 2020 at 08:15, Yvonne Zhang wrote: > Hi, > I have a function streaming a zipreader to browser. It is like this. > func functionA()(body io.ReadCloser, err error){ > >// some logic to get a zipreader > >body, pipeWriter := io.Pipe() >zipWriter :=

Re: [go-nuts] [generics] Allowing interfaces with type constraints

You can definitely use parametric interfaces in type assertion expressions, but you can't use interfaces with type lists. I'm not sure exactly what you're trying to do in your example, but ISTM that it could be somewhat simpler. You only need one type parameter:

Re: [go-nuts] Dynamic composition of interfaces at runtime?

On Wed, 2 Sep 2020 at 10:56, Jesper Louis Andersen < jesper.louis.ander...@gmail.com> wrote: > Usually, my experience is that these highly dynamic interfaces is an > indication you want to approach the problem from a different angle. You > will converge on something that gets closer and closer to

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

On Mon, 24 Aug 2020 at 12:57, 'Richard Oudkerk' via golang-nuts < golang-nuts@googlegroups.com> wrote: > > Applying the same rule to type lists and type switches you should be able > to write > > type Comparer[T any] interface { > Compare(T) int > } > > type CompareConstraints

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

On Mon, 24 Aug 2020 at 06:35, Denis Cheremisov wrote: > I probably didn't read what you have wrote in the first message carefuly > enough. Does it mean something like that will work > > type SomeTypes interface { > type int, float32, float64 > } > > func Min[T SomeTypes](x, y T)

Re: [go-nuts] [ generics] Moving forward with the generics design draft

gt;> > >> On Fri, Aug 21, 2020 at 2:43 PM Axel Wagner > >> wrote: > >> > > >> > also, of course, you could still use operators with them, while now > also knowing the exact semantics of those operators (e.g. in regards to > overflow), which might also be us

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, 21 Aug 2020 at 23:03, Axel Wagner wrote: > On Fri, Aug 21, 2020 at 11:46 PM Ian Lance Taylor wrote: > >> Yes, there are various such possibilities. >> >> What jimmy frasche said above is correct: nothing changes in the case >> of a type switch of a type parameter. The code now knows

Re: [go-nuts] [ generics] Moving forward with the generics design draft

0 at 11:42 PM Axel Wagner < > axel.wagner...@googlemail.com> wrote: > >> > >> > >> > >> On Fri, Aug 21, 2020 at 11:30 PM roger peppe > wrote: > >>> > >>> On Fri, 21 Aug 2020 at 22:10, jimmy frasche > wrote: > >>>> > >>&

Re: [go-nuts] [ generics] Moving forward with the generics design draft

n type such as byte. On Fri, Aug 21, 2020 at 2:07 PM roger peppe wrote: > > > > > > On Fri, 21 Aug 2020 at 01:28, Ian Lance Taylor wrote: > >> > >> After many discussions and reading many comments, we plan to move > >> forward with some changes a

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, 21 Aug 2020 at 01:28, Ian Lance Taylor wrote: > After many discussions and reading many comments, we plan to move > forward with some changes and clarifications to the generics design > draft. > > 1. > > We’re going to settle on square brackets for the generics syntax. > We’re going to

Re: [go-nuts] [ generics] Moving forward with the generics design draft

Oyy9z>. > I agree that's a concern, but I think that should be a reason to fix error messages when aliases are used, not to use a named type. > On Fri, Aug 21, 2020 at 7:08 PM roger peppe wrote: > >> >> >> On Fri, 21 Aug 2020 at 15:24, Ian Lance Taylor wrote: >>

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, 21 Aug 2020 at 15:24, Ian Lance Taylor wrote: > On Fri, Aug 21, 2020, 12:37 AM 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >> Just to clarify, the intent is to make the declaration in the spec `type >> any = interface{}`, not `type any interface{}`, correct?

Re: [go-nuts] [ generics] Moving forward with the generics design draft

On Fri, 21 Aug 2020 at 01:28, Ian Lance Taylor wrote: > After many discussions and reading many comments, we plan to move > forward with some changes and clarifications to the generics design > draft. > > 1. > > We’re going to settle on square brackets for the generics syntax. > We’re going to

Re: [go-nuts] Generics: after type lists

On Sat, 15 Aug 2020 at 04:57, Patrick Smith wrote: > On Thu, Aug 13, 2020 at 11:25 PM Patrick Smith > wrote: > > I tried out a few different implementations, evaluating the polynomial > > instead of finding roots, > > at https://go2goplay.golang.org/p/g8bPHdg5iMd . As far as I can tell, > >

Re: [go-nuts] [ generics ] Concrete example of comparables and generic function types

Nice example! Presumably if you wanted to do actual Porter-Duff though, you'd want some arithmetic rather than just comparison. One observation: you don't actually need the "comparable" constraint on many of the core entities there (e.g. Rect and Op) because they don't actually use any compare

Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

On Thu, 13 Aug 2020 at 23:30, Ian Lance Taylor wrote: > On Thu, Aug 13, 2020 at 3:09 PM roger peppe wrote: > > > > I do feel that the "all or nothing" nature of type parameter lists (if > you specify one type parameter, you must explicitly specify all of the >

Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

That's interesting; thanks for the heads up. My initial reaction is that this perhaps feels a bit "clever", but perhaps this feeling will go away in time. Constraint type inference is useful when a function wants to have a type > name for an element of some other type parameter, or when a

Re: [go-nuts] "Interfaces" with type lists are a strange beast

On Wed, 12 Aug 2020 at 16:43, 李晓辉 wrote: > Maybe `type list` equals to `sum type` > > type SignedInteger interface { >type int, int8, int16, int32, int64 > } > > can replaced by > > type SignedInteger int|int8|int16|int32|int64 > Yes, I've had that thought too (and mentioned it as

Re: [go-nuts] Non-alphanumerics in template field names?

You could use the "index" built-in function instead of the dot operator: {{index . "foo:bar"}} On Fri, 31 Jul 2020, 17:16 Bob DuCharme, wrote: > I have seen that a map key name of "foo:bar" works just fine... unless I > reference it in a template. {{.foo:bar}} gives me a segmentation violation

Re: [go-nuts] json.Unmarshal with disallowUnknownFields

You could write a function to do that for you. On Thu, 30 Jul 2020, 09:45 Brian Candler, wrote: > I want to do a json.Unmarshal of []byte data whilst also getting the > disallowUnknownFields behaviour. Is there any tidier way than this > ? > > dec :=

Re: [go-nuts] Generics and parentheses

On Sat, 18 Jul 2020, 13:25 Jan Mercl, <0xj...@gmail.com> wrote: > On Sat, Jul 18, 2020 at 1:39 PM roger peppe wrote: > > > I didn't say there was exactly one construct for each kind of name > definition. In current Go, when a name is defined, it's defined inside a > cons

Re: [go-nuts] Generics and parentheses

On Sat, 18 Jul 2020 at 11:05, Jan Mercl <0xj...@gmail.com> wrote: > On Sat, Jul 18, 2020 at 11:12 AM roger peppe wrote: > > Thanks for taking time to think about it. > > > A few reasons that I'm not keen on your $, @ proposal: > > > > - elsewhere in Go, when a

Re: [go-nuts] Generics and parentheses

On Thu, 16 Jul 2020, 14:38 Jan Mercl, <0xj...@gmail.com> wrote: > On Thu, Jul 16, 2020 at 3:12 PM 'Axel Wagner' via golang-nuts > wrote: > > > I dislike the idea of using $ and @ because I don't want to add new > symbols to the language, if it can be avoided. In general I'd argue that Go > tends

Re: [go-nuts] [generics] Issues with identifying the matched predeclared type

On Wed, 8 Jul 2020 at 00:33, Steven Blenkinsop wrote: > On Tue, Jul 7, 2020 at 10:44 AM, roger peppe wrote: > >> >> In my description, there's no assumption that doing it over the type >> parameter implies a refinement of the previously set type constraints. In >&

Re: [go-nuts] [generics] Issues with identifying the matched predeclared type

On Tue, 7 Jul 2020 at 21:05, Tobias Gustafsson < tobias.l.gustafs...@gmail.com> wrote: > Den tisdag 7 juli 2020 kl. 16:45:21 UTC+2 skrev rog: >> >> On Tue, 7 Jul 2020 at 10:36, Tobias Gustafsson >> wrote: >> >>> Hi all, >>> >>> Thanks for the response on this subject! >>> >>> Yes, a kind of type

Re: [go-nuts] [generics] Issues with identifying the matched predeclared type

y to avoid nesting type switches (in a normal type >> switch, it's possible to assign the specialized value to another variable >> with wider scope, but that's not possible in general with generic type >> switches). However, it may be too confusing syntactically with the normal >>

Re: [go-nuts] [generics] Issues with identifying the matched predeclared type

and could be omitted. It depends how commonly used this might be. On Tue, 7 Jul 2020 at 04:51, Steven Blenkinsop wrote: > On Mon, Jul 6, 2020 at 6:29 PM, roger peppe wrote: > >> >> I've also been playing around in this area. I've been trying something >&g

Re: [go-nuts] [generics] Issues with identifying the matched predeclared type

On Mon, 6 Jul 2020 at 17:46, wrote: > Hi! > > I've spent some time lately to try out the go2go tool and the new generics > proposal by converting a small hack I did some years ago for immutable data > structures (https://github.com/tobgu/peds) which, in it's current shape, > depends on code

Re: [go-nuts] Re: [generics] Generics pave the way to some kind of polymorphism implementation?

When you say "polymorphism", I think you might mean "inheritance"? (Go-with-generics already has two kinds of polymorphism) I don't really understand what you're trying to accomplish here. Perhaps you could explain your motivation a bit more? On Fri, 3 Jul 2020, 21:22 Aleksandar Milovanović,

Re: [go-nuts] draft design for // +build replacement

LGTM. This is a welcome change. I often need to look up how to spell "// +build" currently :) One thing I'd really like to see is the eventual deprecation of filename-based build constraints (e.g. file_linux.go). They make it hard for users (not everyone knows the name of all architectures), hard

Re: [go-nuts] [Generics] Concise generics with package level types

The draft proposal does not support generic function values. Doing so would make the compiler's code generation job much harder (or maybe not possible) because it would be considerably more difficult to enumerate all the possible instantiation parameters at compile time. On Wed, 24 Jun 2020,

Re: [go-nuts] [Generics] Concise generics with package level types

On Tue, 23 Jun 2020 at 17:33, wrote: > Imagine the following function definition, under the current proposal (I > believe this is correct): > > > func (s MyMap(K, V)) DoSomething(k K, v V) (func(type K Hashable) (k K) (V, > error)) {...} > > I don't think that's quite right. You can't have

Re: [go-nuts] Why not use F in generic？

On Tue, 23 Jun 2020 at 03:04, Ian Lance Taylor wrote: > On Mon, Jun 22, 2020 at 6:19 PM 移库海牙客 wrote: > > > > I agree the syntax should be more readable and easier to understand. But > I think the current syntax is less readable. > > For example: > > > > type I2 interface { > > (I1(int)) > > } >

Re: [go-nuts] [generics] constraint for nillable types?

FWIW I also came across this issue recently in a different context and similarly wondered if a nillable constraint might be a good idea. There is a kinda workaround although you won't like it :) https://go2goplay.golang.org/p/-nDAUVYWuxo On Tue, 23 Jun 2020 at 05:43, 'Bryan C. Mills' via

Re: [go-nuts] Block-based data structures and the Type Parameters - Draft Design

On Mon, 22 Jun 2020 at 22:49, Andrew Werner wrote: > > > On Monday, June 22, 2020 at 5:42:12 PM UTC-4, rog wrote: >> >> >> Thanks for pointing this out. I'm cool with this approach. I'll update my library to utilize it (and consider also adopting the list.List, though I do like my

Re: [go-nuts] Block-based data structures and the Type Parameters - Draft Design

> Thanks for pointing this out. I'm cool with this approach. I'll update my >> library to utilize it (and consider also adopting the list.List, though I >> do like my freedom to pool list nodes). >> > Personally, I'd start by re-using list.List, and only use pools if there really is a significant

Re: [go-nuts] Block-based data structures and the Type Parameters - Draft Design

On Mon, 22 Jun 2020 at 15:57, Andrew Werner wrote: > On Monday, June 22, 2020 at 10:17:01 AM UTC-4, rog wrote >> >> On Mon, 22 Jun 2020 at 14:59, Andrew Werner wrote: >> >>> Oh! It’s saying that *B implements the constraint, nifty. Is this idea >>> in the current proposal? >>> >> >> Yes. See >>

Re: [go-nuts] Block-based data structures and the Type Parameters - Draft Design

On Mon, 22 Jun 2020 at 14:59, Andrew Werner wrote: > > > On Mon, Jun 22, 2020 at 9:45 AM roger peppe wrote: > >> >> >> On Mon, 22 Jun 2020 at 14:26, Andrew Werner wrote: >> >>> Hey Rog, >>> >>> I think I sent you a private reply ea

Re: [go-nuts] Block-based data structures and the Type Parameters - Draft Design

On Mon, 22 Jun 2020 at 14:26, Andrew Werner wrote: > Hey Rog, > > I think I sent you a private reply earlier. My bad. I now see what you're > proposing in the first proposal think it makes a lot of sense. > > The thing that I think I had missed was this piece of magic: > // New returns a new

Re: [go-nuts] Block-based data structures and the Type Parameters - Draft Design

Thanks for the interesting use case, Andrew! I've experimented with a slightly different approach: https://go2goplay.golang.org/p/AkqzbWmpj6t It expects the caller to implement a method on the array to get a reference to the underlying storage, but that's fairly trivial to implement. I've

Re: [go-nuts] Re: [generics] (again). Type inference is somewhat weak

Yes, I agree. It seems to have trouble inferring types when the argument is a generic interface type. Here's a simpler example: https://go2goplay.golang.org/p/3-aVhD6Y9R2 I think this is probably https://github.com/golang/go/issues/39661 cheers, rog. On Thu, 18 Jun 2020 at 02:14, Denis

  1   2   3   4   5   >