Re: [go-nuts] problem with generic type switch

Yes, the *underlying type* of Class is `byte`, but the type-switch checks if the dynamic type is *exactly* `byte`. The only way, currently, to implement the kind of check you want is to use reflect: switch rv := reflect.ValueOf(v); rv.Kind() { case reflect.Uint8: // byte v := uint8(rv.Uint())

Re: [go-nuts] [generics] type constraint for structs

How does `interface{ AsElement() *Element }` not do exactly what you want? On Thu, Apr 4, 2024 at 4:14 AM atd...@gmail.com wrote: > Might have come across this today as I was trying to simplify some code. > > Basically, I have a base type called *Element that has a method > AsElement() *Element

Re: [go-nuts] Module vs Package

A package is the unit of compilation - the entire package is compiled in a step and it's also where unexported names are scoped to. A module is the unit of versioning - it's a bunch of packages versioned and distributed together. On Mon, Apr 1, 2024 at 8:43 AM Nikhilesh Susarla wrote: >

Re: [go-nuts] Nil pointer panic that should be impossible

elps, it's a bit subtle. >>> >>> On Mon, Mar 25, 2024 at 1:35 PM 'Lirong Wang' via golang-nuts < >>> golan...@googlegroups.com> wrote: >>> >>>> Wow, i am from other language and i thought `string` is immutable or >>>> something like

Re: [go-nuts] Nil pointer panic that should be impossible

ng new!!! Thanks >>> On Thursday, March 21, 2024 at 11:42:24 PM UTC+8 Ethan Reesor wrote: >>> >>>> I hadn't used the race detector before. I do see a race warning for >>>> (*URL).String() among an embarrassing number of other results. I'm going to >>>> update (

Re: [go-nuts] Nil pointer panic that should be impossible

her results. I'm going to >> update (*URL).String() to use atomic.Pointer to remove the race. >> >> Thanks, >> Ethan >> >> On Thu, Mar 21, 2024 at 8:59 AM 'Axel Wagner' via golang-nuts < >> golan...@googlegroups.com> wrote: >> >>> On

Re: [go-nuts] Nil pointer panic that should be impossible

On Thu, Mar 21, 2024 at 2:48 PM 王李荣 wrote: > hi Axel, > > is not modifying `u.memoize.str` thread-safe? the len and the data point > should become visible at same time? > What makes you think that? To be clear, there are no benign data races. Even a data-race on a variable smaller than a word

Re: [go-nuts] Nillable basic types?

FWIW I believe (as Brian sort of points out) this proposal is fully subsumed under #57644 . Under that proposal, the proposed type `int | nil` would be spelled `interface{ int }`. The other syntactical constructs are, as far as I can tell, identical -

Re: [go-nuts] Nil pointer panic that should be impossible

Have you tried running the code with the race detector enabled? I suspect that you are concurrently modifying `u.memoize.str` by calling `u.String()` from multiple goroutines. And the non-zero length of the string header written by one goroutine becomes visible to the other one, before the

Re: [go-nuts] x/pkgsite docs wrongly assume $PATH includes $GOPATH/bin

On Thu, Feb 29, 2024 at 9:12 AM kredop...@gmail.com wrote: > Apologies - sent the response only to you, so I'll write it again here. > > > Doesn't the `go install` command explicitly instruct you to add > $GOBIN/$GOPATH/bin to your $PATH? > > I did check both golang installation docs and the

Re: [go-nuts] Equality of interface of an empty struct - why?

cause of the assumption that pointers never change. This > is implied by the spec but easy to miss. > > "Pointers to distinct zero-size variables may or may not be equal." > "Pointers to distinct zero-size variables may or may not be equal and the > results may or may not

Re: [go-nuts] x/pkgsite docs wrongly assume $PATH includes $GOPATH/bin

Doesn't the `go install` command explicitly instruct you to add $GOBIN/$GOPATH/bin to your $PATH? To me, that seems enough - it feels a bit arduous, to expect this piece of information at any single point on the web where `go install` is mentioned. On Thu, Feb 29, 2024 at 1:39 AM Robert Sawicki

Re: [go-nuts] Equality of interface of an empty struct - why?

variables may or may not be equal and the >> results may or may not be repeatable in any context." >> >> Agree once a programmer is aware of the behavior it can be avoided. >> >> Best, >> Brien >> >> >> On Feb 27, 2024, at 3:06 PM, 'Axel Wagner'

Re: [go-nuts] Equality of interface of an empty struct - why?

On Tue, Feb 27, 2024 at 8:19 PM Marvin Renich wrote: > Prior to generics, the type of the > arguments to == were easily known to the programmer, and so it was > obvious when this "undefined" exception would raise its ugly head, and > you just didn't use it for empty struct types. But now, with

Re: [go-nuts] Equality of interface of an empty struct - why?

On Mon, Feb 26, 2024 at 7:25 PM Brien Colwell wrote: > Interesting. That seems to break the comparable spec. > > >> Pointer types are comparable. Two pointer values are equal if they > point to the same variable or if both have value nil. Pointers to distinct > zero-size variables may or may not

Re: [go-nuts] Re: Equality of interface of an empty struct - why?

I think you should still wait for the outcome of that issue. On Mon, Feb 26, 2024 at 10:39 AM brien colwell wrote: > I learned a lot from this thread, thank you. > > Intuitively the spec seems to conclude a pointer to an empty struct is a > different type of pointer? Normally a pointer wouldn't

Re: [go-nuts] Equality of interface of an empty struct - why?

FWIW I believe there is enough subtlety here (small changes in the code might trigger different compiler optimizations) that I wouldn't rely too much on probing the compiler with different programs. Instead, I'd suggest decompiling the binary and/or running it in a debugger, to check what the

Re: [go-nuts] Equality of interface of an empty struct - why?

>From the spec : > A struct or array type has size zero if it contains no fields (or elements, respectively) that have a size greater than zero. Two distinct zero-size variables may have the same address in memory. On Thu, Feb 22, 2024 at

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

On Wed, Feb 21, 2024 at 1:36 AM Sam Vilain wrote: > I had a brief look on the Golang issues in Github and could not find any > prior proposals along this line using "context" and "dynamic scope" as > search terms, so I'll submit this as a "new" proposal for now > FWIW some prior discussion on

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

If I may quote myself: > And no matter which choice you make for the language - it means that if the programmers wanted the other, they'd have to jump through annoying hoops and get confusing and hard to debug problems. Having a mechanism to get one or the other semantic doesn't change the fact

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

On Sat, Feb 17, 2024 at 2:09 AM Sam Vilain wrote: > I would argue that the matter can be simply decided by choosing the > *calling* stack, not the destination stack. > I agree that this is *one choice*. But the point is, that *sometimes* you'd want one and *sometimes* the other. And no matter

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

FWIW the common name for this is "dynamic scope": https://en.wikipedia.org/wiki/Scope_(computer_science)#Dynamic_scope The general reason this has not been accepted for Go, is that passing a Context explicitly removes ambiguities what is meant, in the presence of closures and goroutines. If you

Re: [go-nuts] "yield" is backwards

I'm not sure what you mean. The `yield` function does exactly the same as Python's `yield` statement and in fact, that's part of why the name was chosen. Compare Python: def vals(a): for v in a: yield v for x in vals([1,2,3]): print(x) With Go: func vals[T any](s []T)

Re: [go-nuts] New type in generics

The way to do that is to add another level of indirection (as everything in Software Engineering): type Namer[T any] interface { *T SetName(name string) } func WithName[T any, PT Namer[T]](name string) T { var v T PT().SetName(name) return v } I will say, though, that it's

Re: [go-nuts] Does building with an older golang use package sources from that older version?

You don't even need to run `go clean`. Go will automatically detect whether stuff needs to be rebuilt, as the Go version used to build a package is part of a hash, that is used as a key for the build cache. And yes, it will use the standard library packages of the Go version that is installed (the

Re: [go-nuts] Type parameter embedded field

I think that might work, yes. At least I don't see a major issue with it right now. On Tue, Jan 9, 2024 at 7:25 PM roger peppe wrote: > > > On Fri, 5 Jan 2024 at 05:58, 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >> Hi, >&g

Re: [go-nuts] Incorrect "missing return" error for an edge case

The "missing return" error is defined in the spec, by requiring a function to end in a terminating statement: https://go.dev/ref/spec#Terminating_statements The list is necessarily not complete. So it is necessarily more advisory than anything else. What things to put in is mainly limited by how

Re: [go-nuts] Type parameter embedded field

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 X[T any] struct { T *bufio.Reader } func main() { var x X[int] x.Read // definitely refers to

Re: [go-nuts] How to create a generic factory?

Note that your code is not type-safe. It panics when instantiated with a type that does not use a pointer receiver: https://go.dev/play/p/eHUKtXvgwAu ISTM that being more type-safe would be an advantage here. On Sat, Dec 30, 2023 at 8:47 PM Mazen Harake wrote: > @Alex, > > Oh, and I should

Re: [go-nuts] How to create a generic factory?

1. Note that you can just write `NewMessage({}, buf)` in your example, as the type can be inferred. 2. You can use a constraint on a pointer-receiver to somewhat simplify that: https://go.dev/play/p/pEu02Bn9t3f That is not *quite* what you are asking for. It is not actually possible to really do

Re: [go-nuts] Re: Why there is no net.ListenContext?

Hm, reading again, I don't think I actually understand your question. You clearly are ListenConfig aware. But what do you mean with "the same way we have Dial and DialContext"? These are methods on Dialer, so ISTM that there is indeed a pretty clear correspondence. Except that Dialer.Dial has been

Re: [go-nuts] Re: Why there is no net.ListenContext?

You can use `ListenConfig.Listen` to do this: https://pkg.go.dev/net#ListenConfig.Listen I believe the reason to do it this way was the realization that there will probably be more ways to set up listening in the future and having lots of different ListenFoo functions in the package would overload

Re: [go-nuts] slog formatter funcs? (e.g. slog.Infof)

I believe the intention is that you shouldn't format this, but make `err` an `Attr`. i.e. the philosophy behind structured logging is specifically, not to do formatting, as it produces unstructured data. Whether I'm personally convinced by that philosophy is another question, but I think that's

Re: [go-nuts] Generic type for struct method: constraint problem && cannot use (untyped string constant) as string value

I agree that it is an unfortunate error message, but to be clear, it is entirely correct - you are defining a new type called `uint8` and it is indeed not possible to assign an untyped integer constant to that, as its underlying type is a type parameter (constrained on any). I'm pretty sure there

Re: [go-nuts] Generic type for struct method: constraint problem && cannot use (untyped string constant) as string value

Yes, this has come up before. On Fri, Nov 10, 2023 at 7:09 AM ahuigo wrote: > There is an example: https://go.dev/play/p/guzOWRKi-yp > > ``` > func (c *cachedFn[string, V]) Get0() (V, error) { > // var s any > var s string > s = "abc" // error: cannot use "abc" (untyped string constant) as

Re: [go-nuts] Can Generics match implementers of an interface?

nd less that invent > generics...? ¿I'm the lazy one that rants for having to learn new types > theory? > > and After a few drinks: First Object class now interface{} struct... > you both have everything... generics... keep it simple please... don't > become Scala... > &

Re: [go-nuts] Can Generics match implementers of an interface?

I think addressing this would sensibly include a rule to allow unifying two types, if one is assignable to the other (which, AIUI, we already do for directional channels). It's possible that this can be confusing in some circumstances including composite types e.g. something like func Append[T

Re: [go-nuts] Can Generics match implementers of an interface?

This is purely a type-inference problem. If you explicitly instantiate `Append`, it works: https://goplay.tools/snippet/15RFAPFPl3y Type inference is still relatively limited. It might become possible to at some point omit the instantiation. I think this might be "Inferring based on interfaces" in

Re: [go-nuts] Can we not invoke methods on types referring to generics?

On Fri, Oct 20, 2023 at 1:07 PM Nurahmadie Nurahmadie wrote: > This statement doesn't feel right to me, one can always do `type NewType > struct{}` to create genuinely new types, but if you do `type String > string`, for example, surely you expect String to has `string` value, hence > there will

Re: [go-nuts] Can we not invoke methods on types referring to generics?

FWIW I think what OP is ultimately asking about is some form of nominal subtyping. When they say "automatic upcasting", they refer (I believe) to what Go calls "assignability", which is in essence a subtype relationship. So they want to be able to define a new type, that is a subtype of an

Re: [go-nuts] Generic "nillable" constraint

On Wed, Oct 18, 2023 at 5:24 PM Jon Watte wrote: > I think "making all values comparable" is a worse change though (there's a > reason they aren't comparable!) > FTR the proposal was not to make all values comparable, but to make all values comparable to the predeclared identifier nil - similar

Re: [go-nuts] Generic "nillable" constraint

On Wed, Oct 18, 2023 at 6:09 AM Jon Watte wrote: > Circling back to this, because it came up today again. > > Here's the generic function I want to write. It comes up in a lot of > function composition, which in turn comes up in a lot of interface adapters > and such: > > func maybeAssign[T

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

It is not "meant for tests internal to the http package". It's meant for tests of users of the `net/http` package. That is, implementations of the `http.Handler` interface. In the context of the standard library, that is what "general purpose HTTP testing" means. On Tue, Oct 17, 2023 at 10:44 AM

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

To be clear: The behavior of an `http.ResponseWriter` to implicitly use a 200 status code if no explicit WriteHeader call is made is documented: https://pkg.go.dev/net/http#ResponseWriter.WriteHeader I really think it is a bad (or at least strange) idea to claim to implement `http.ResponseWriter`

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

It seems to me that the fact that the functions accept and return types from `net/http` (like `http.ResponseWriter` and `http.Handler`) and given that it's nested below `net/http` should make it fairly obvious that it's meant to be used with `net/http`. I also genuinely don't understand what the

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

If you want to argue that `net/http` should not set the response code to 200 by default, I would be inclined to agree. I don't particularly like that the API even *allows* you not to explicitly set a response code. But it does. And while it does, the best test is one that matches the behavior of

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

A default `net/http` server also uses 200 as the default response code. The behavior of an `http.Handler` not setting a response code should be the same, if it uses `httptest`, as if it uses `net/http`. On Sun, Oct 15, 2023 at 5:17 PM Simon Walter wrote: > Hi all, > > What is the reason that

Re: [go-nuts] Re: Why causes []any trouble in type equations?

On Wed, Oct 11, 2023 at 8:11 PM Torsten Bronger < bron...@physik.rwth-aachen.de> wrote: > Then, all boils down to the fact that you can’t pass []float64 as an > []any. To be honest, I still don’t fully understand why this is > forbidden What would this do? func F(s []any) { s[0] = "Foo" }

Re: [go-nuts] Re: Why causes []any trouble in type equations?

In the first example, the inferred type is `float64`, so the signature of the function is `func do([]float64)`. You can obviously pass a `[]float64` to it. If X is a concrete (i.e. non-interface) type, then `func F[T X]()` is syntactic sugar for `func F[T interface{ X }]()`, which is a constraint

Re: [go-nuts] Why causes []any trouble in type equations?

In the second case, the type argument is inferred to be `[]float64`. The constraint on `T` in `do` is that it has to be `[]any`. `[]float64` is not `[]any`, the two are different types, so instantiation fails. Note that even if you explicitly instantiate `do` to `[]any`, you still could not pass a

Re: [go-nuts] The docs for secretbox seem very wrong

I get the impression that the thing you are missing is that appending to a slice does not modify it. That is, `append(s, x...)` modifies neither the length, nor the content of `s`, you have to type `x = append(s, x...)`. `Seal` (and `Open`) work exactly the same. They append to the `out` parameter

Re: [go-nuts] The docs for secretbox seem very wrong

For what it's worth, here is an example that demonstrates a typical encryption/decryption roundtrip, perhaps more clearly: https://go.dev/play/p/ZZry8IgTJQ_- The `out` parameter can be used to make this more efficient by using pre-allocated buffers (depending on use case) and there are cases where

Re: [go-nuts] The docs for secretbox seem very wrong

oh I forgot to emphasize: I don't believe the output is *really* ``. That is, I don't believe you can really treat the first N bytes as the encrypted text and decrypt it (say, if you didn't care about the authentication). It's just that you ultimately need to add 16 bytes of extra information to

Re: [go-nuts] The docs for secretbox seem very wrong

I don't really understand your issue. You call encrypted := secretbox.Seal(nonce[:], []byte(s), , ) That means you pass `nonce[:]` as the `out` argument, `s` as the `message` argument, and the nonce and key and assign the result to `encrypted`. According to the docs of `secretbox`, `Seal` will

Re: [go-nuts] Generic "nillable" constraint

Oh (sorry, being forgetful) and re "it's less of a new mechanism than introducing a zero identifier": #62487 introduces *even less* new mechanism, by expanding comparison to (and assignment of) `nil` to all types inside a generic function. It's not a new

Re: [go-nuts] Generic "nillable" constraint

(correction: It should be Convert[J isinterface, T J]. I changed the name from I to J to be more readable and then missed one occurrence) On Wed, Oct 4, 2023 at 7:33 AM Axel Wagner wrote: > On Wed, Oct 4, 2023 at 6:54 AM Jon Watte wrote: > >> > where it is important to permit only type

Re: [go-nuts] Generic "nillable" constraint

On Wed, Oct 4, 2023 at 6:54 AM Jon Watte wrote: > > where it is important to permit only type arguments that can be compared > to nil > > I see! As in, if we somehow got a "equalszero" constraint, then that > constraint would solve the problem I illustrate. > I believe that assertion is correct,

Re: [go-nuts] Generic "nillable" constraint

On Tue, Oct 3, 2023 at 9:06 PM Jon Watte wrote: > I don't want to include int or struct{} in this case. I care specifically > about "can be compared to nil" > The only thing I can do with a type parameter that is only constrained as > "nil" is compare it to nil, or assign nil to it. > This means

Re: [go-nuts] Generic "nillable" constraint

It doesn't solve the problem. That function signature you wrote could not be instantiated by `int`, for example. You can't write `comparable | nil`, as `comparable` is not allowed in a union. And if we allowed it, there would be no way to write the body of the function. It doesn't help with types

Re: [go-nuts] What is a ordinary and exceptional error?

On Sun, Oct 1, 2023 at 2:37 PM Jerry Londergaard wrote: > I've been thinking about this point as well lately. I think I understand > (at least some of) the conditions under which > you would call a panic(), but I still don't quite grok why it's better > than returning an error if that error is

Re: [go-nuts] About variables have per-iteration scope instead of per-loop scope

So, how often do you depend on this particular scoping behavior, in Go or JS? Do you have any example of where you intentionally rely on the current behavior, that might break with the new one? I think it's important to emphasize that we do not know of a *single case* where the current behavior

Re: [go-nuts] About variables have per-iteration scope instead of per-loop scope

This has come up during the discussion already. I don't know enough about other languages to speak with confidence, but apparently there already is precedent for this and/or some languages are at least considering making a similar change. Note that scoping rules already vary between languages -

Re: [go-nuts] Encrypting a small secret using curve25519

To be clear: I'm by no means an expert, so take my advice with a huge grain of salt (pun intended). But from what it seems, with no offense intended, neither are you. On Wed, Sep 20, 2023 at 10:32 AM Axel Wagner wrote: > As I understand it, ed25519 is using Curve25519 in EdDSA, which is a >

Re: [go-nuts] Encrypting a small secret using curve25519

As I understand it, ed25519 is using Curve25519 in EdDSA, which is a signing scheme. So using "ed25519" for encryption does not make any sense. NaCl also uses Curve25519, ultimately using ECDH (again, as I understand it) to establish a secret key for Salsa20. So it is pretty fundamentally

Re: [go-nuts] Using go module 101, undefined types

The code you posted does not actually contain the string `api.PetStore`, so it seems to be incomplete. From extrapolation, I agree that it should work, so the issue must be in that incomplete part. On Mon, Sep 11, 2023 at 11:23 PM Tong Sun wrote: > This is really a go module 101 question, as

Re: [go-nuts] Why is pdfcpu v0.5.0 290MiB on proxy.golang.org ?

Not sure if it's a good idea, but you could put them in a separate Go module and only import that from tests. That way they *should* not get downloaded when the module is only imported as a dependency. I think. OTOH you'd have to use `go:embed` to export them, which means every `go test` has to

Re: [go-nuts] Why is pdfcpu v0.5.0 290MiB on proxy.golang.org ?

ISTM that's because they include a lot of PDFs for samples and test data in their repository now: https://github.com/pdfcpu/pdfcpu/tree/master/pkg/samples (245 MB) https://github.com/pdfcpu/pdfcpu/tree/master/pkg/testdata (77 MB) This isn't due to the module mirror doing anything weird, it's just

Re: [go-nuts] How to try out the new range func CL in a module

(or change the `go` directive to `Go 1.21` (no minor version) apparently) On Tue, Aug 22, 2023 at 7:52 AM Axel Wagner wrote: > By coincidence, I was just reading https://go.dev/blog/toolchain and > realized I put `GOTOOLCHAIN=local` into my ~/.confiig/go/env a while ago, > so as to not have the

Re: [go-nuts] How to try out the new range func CL in a module

By coincidence, I was just reading https://go.dev/blog/toolchain and realized I put `GOTOOLCHAIN=local` into my ~/.confiig/go/env a while ago, so as to not have the Go tool transparently download different versions. If I remove that, I can indeed reproduce the behavior you are seeing. So, my

Re: [go-nuts] How to try out the new range func CL in a module

Your `gotip` version seems to be at Go 1.21.0, not at the `rangefunc` experiment CL. `gotip version` should say `go version devel go1.21-ca691a8566 Tue Jul 18 10:30:20 2023 -0400 (w/ rangefunc) linux/amd64` - regardless of the contents of the `go.mod`, as far as I know. At least I can't reproduce

Re: [go-nuts] How to try out the new range func CL in a module

Hm. For me, it still enables the rangefunc experiment, even though go.mod says go 1.21: mero@vetinari ~/tmp/x$ gotip version go version devel go1.21-ca691a8566d Tue Jul 18 10:30:20 2023 -0400 (w/ rangefunc) linux/amd64 mero@vetinari ~/tmp/x$ cat go.mod module x go 1.21 mero@vetinari ~/tmp/x$ cat

Re: [go-nuts] keyword= support for function calls

The reason `os.Open` has not changed is because it doesn't have to change. None of the features you mention really make sense for what it does. At least that would be my interpretation. If you want to support your interpretation, I would suggest digging up proposals to add those features which got

Re: [go-nuts] keyword= support for function calls

Have a look at net.Dialer . It is essentially a struct that adds optional, keyword arguments to net.Dial . On Thu, Aug 17, 2023 at 3:44 AM Jon Perryman wrote: > Struct does not solve the basic problem. In what way are you suggesting to

Re: [go-nuts] Generic zero value for compiler optimization

You might be interested in https://github.com/golang/go/issues/61372 On Mon, Aug 14, 2023 at 3:52 PM Diego Augusto Molina < diegoaugustomol...@gmail.com> wrote: > Hi, thank you for reading. Whenever I need to use a zero value for a > generic type in a func I do something like the following: > >

Re: [go-nuts] Why does Go (so far) not have support for generators/ iterators for custom types ?

Small corrections: 1. in the first sentence, add an "early days Go" 2. In the second sentence, "now we do have *generics*", not iterators. On Sun, Aug 6, 2023 at 11:35 AM Axel Wagner wrote: > For one, Go did not have generic types or functions, which really limits > the usefulness (and

Re: [go-nuts] Why does Go (so far) not have support for generators/ iterators for custom types ?

For one, Go did not have generic types or functions, which really limits the usefulness (and abilities to write) custom iterators in Go. Now we do have iterators, but it turns out there still are a lot of subtle Go-specific issues with how to support custom iterator types, which to be honest are

Re: [go-nuts] Clarification on code snippet

Another relevant section is Calls (emphasis mine): > A method call x.m() is valid if the method set of (the type of) x contains > m and the argument list can be assigned to the parameter list of m. *If x > is addressable and 's method set contains m, x.m() is

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

section "Expression statements" we read that "The following >>>>>>>> built-in functions are not permitted in statement context: >>>>>>>> >>>>>>>> append cap complex imag len make new real >>>>>&g

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

>>> Although the sentence is OK as it stands, the section should be tweaked >>> a bit. One of the examples there (myString(0x65e5)) is valid Go but vet >>> rejects it, as part of the move towards disallowing this conversion, which >>> was there mostly for bootstrappin

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

2:02:27 UTC+2 Rob Pike napisał(a): > >> Although the sentence is OK as it stands, the section should be tweaked a >> bit. One of the examples there (myString(0x65e5)) is valid Go but vet >> rejects it, as part of the move towards disallowing this conversion, which >> was there mostly

Re: [go-nuts] Re: Generics and "static" adapters

Why not remove the `recordFactory` type then? type Record interface { Key() string Marshal() []byte Unmarshal([]byte) error } func put[R Record](db *SimpleDatabase, t UpdateTransaction, v R) error { k := v.Key() b := v.Marshal() if err := db.put(t, k, b); err != nil {

Re: [go-nuts] Re: error handling thoughts

It's not a compiler error, but OP is probably referring to golint. FWIW I also prefer the `if v, err := fn(); err != nil { … }` form, in general, but in cases like these I just write v, err := fn() if err != nil { // handle error and return } // do thing with v I honestly don't see a huge

Re: [go-nuts] testing whether two maps are the same object

On Tue, Jul 18, 2023 at 5:22 PM Jochen Voss wrote: > Dear Jason, > > Thanks for the idea of using reflect. Do you know whether > `reflect.ValueOf(a).UnsafePointer()` is somehow "safer" than > `*(*uintptr)(unsafe.Pointer())`? > For what it's worth: I'd argue comparing

Re: [go-nuts] Go 1.21 new builtin function clear()

On Thu 6. Jul 2023 at 09:41, Henry wrote: > 'make' allocates the required memory. Does it? What about channels and maps? 'len' returns the length. What’s the “length” of a channel? What’s the “length” of a map? 'cap' returns the capacity. For maps? These questions are rhetorical, for

Re: [go-nuts] Where are closure storing the captured variables ?

It depends a bit on escape analysis. I think the easiest way to reason about it is to say that they are stored in the `func` value. If the `func` value escapes, than so do the closed-over variables. If it doesn't (and the closed-over variables are not otherwise escaped) they don't. At least to an

Re: [go-nuts] Go 1.21 new builtin function clear()

Oh and FWIW: You are right (in my opinion) that the different things `clear` does are, well, different. But note that clear is not the only builtin for which that is the case. `make`, `len` and `cap` all do different things (to varying degrees) on maps, slices and channels. That's not necessarily

Re: [go-nuts] Go 1.21 new builtin function clear()

On Thu, Jul 6, 2023 at 7:49 AM Henry wrote: > So, if I get this right, clear on map will result in map length equals to > zero, but clear on slice is only a value-zeroing operation and the slice > length remains unchanged? That understanding is correct. > They seem like two different

Re: [go-nuts] Go 1.21 new builtin function clear()

Hi, this has come up on the issue as well. Robert Griesemer provided an explanation : If the argument type (the type of the argument provided to clear) is a type > parameter (is of type parameter type), all types in its type set

Re: [go-nuts] Please consider voting to reopen Golang subreddit

On Tue, Jun 27, 2023 at 12:10 AM Eltjon Metko wrote: > The commercial dispute is between Reddit and API Consumers. it has nothing > to do with mods or the users. > Then why are the mods and users protesting? > No-mater how certain you may be who is in the right and who is in the > wrong, the

Re: [go-nuts] Please consider voting to reopen Golang subreddit

On Mon, Jun 26, 2023 at 6:53 PM Eltjon Metko wrote: > Protests like this (temporary) never make sense, they only create > inconvinience for users while reddit will just have to ride it out. Note that the common hypothesis is that there is a reason reddit is so urgently pushing through the API

Re: [go-nuts] Please consider voting to reopen Golang subreddit

On Sat, Jun 24, 2023 at 3:03 AM cpa...@gmail.com wrote: > If 100 people are on a boat and 51 want to sink the boat is that fair to > the 49 who want to live? This is not a life-or-death situation and such comparisons are almost universally unhelpful, as you literally do not have a choice in

Re: [go-nuts] Please consider voting to reopen Golang subreddit

On Fri, Jun 23, 2023 at 10:29 AM Jan Mercl <0xj...@gmail.com> wrote: > On Fri, Jun 23, 2023 at 10:18 AM Axel Wagner > wrote: > > > Just for context, as not everyone seems to be aware: I was, in that > sentence you quoted, referring to examples like this > > >

Re: [go-nuts] Please consider voting to reopen Golang subreddit

that is happening. Not claiming that they already have it. On Fri, Jun 23, 2023 at 10:08 AM Axel Wagner wrote: > There exists more than one subreddit. > > On Fri, Jun 23, 2023 at 9:38 AM Jan Mercl <0xj...@gmail.com> wrote: > >> On Fri, Jun 23, 2023 at 7:01 AM 'Axel

Re: [go-nuts] Please consider voting to reopen Golang subreddit

There exists more than one subreddit. On Fri, Jun 23, 2023 at 9:38 AM Jan Mercl <0xj...@gmail.com> wrote: > On Fri, Jun 23, 2023 at 7:01 AM 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > > > And even *when* they ask and get overwhelming backi

Re: [go-nuts] Please consider voting to reopen Golang subreddit

On Thu, Jun 22, 2023 at 11:04 PM cpa...@gmail.com wrote: > Anyone can choose to stop reading it or posting to it. Opening it will not > stop individuals from protesting. > I'm going to state the obvious: Given that closing it was an act of protest, opening it will certainly stop *some*

Re: [go-nuts] Unexpected circular type definition limitation

Type declarations in functions are only scoped from the point of their declaration until the end of the function. So the reason you can not do the recursive type definition in a function is that at the point of the first declaration, the second is not yet in scope. Package scoped declarations are

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

Ah, the spec does actually say: > > Converting a signed or unsigned integer value to a string type yields a > string containing the UTF-8 representation of the integer. Values outside > the range of valid Unicode code points are converted to "\uFFFD". Personally, I think this is fine as is. I

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

I'm not entirely sure. I don't think your phrasing is correct, as it doesn't represent what happens if the integer value exceeds the range of valid codepoints (i.e. if it needs more than 32 bits to represent). That being said, the sentence as is also isn't really precise about it. From what I can

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

If it helps, I don't think I really understand the generics parts of the spec myself. On Sat, Jun 10, 2023 at 7:13 PM Kamil Ziemian wrote: > This is not a complaint, but a reflection. I have read, as careful as I > can, the half of the Go Spec and if I didn't learn how parametric > polymorphism

Re: [go-nuts] Detecting race conditions

I think the race detector is already relatively good at this. Like, AIUI, it keeps track of the partial order of events and checks if that is consistent and doesn't *purely* rely on writes actually happen concurrently. I suspect (based on little) that in this case, the synchronization points that

  1   2   3   4   5   6   7   8   9   10   >