Re: [go-nuts] Nillable basic types?

On Tue, Mar 19, 2024 at 11:44 AM Daniel Lepage wrote: > I'm not proposing that *any* value be made nillable, I'm proposing the > explicit syntax > > var x uint8 | nil > > that would create a nillable uint8. A variable of type `byte` would still > only take up one byte; a variable of type `byte |

Re: [go-nuts] Re: Range over int

On Fri, Feb 16, 2024 at 10:27 PM Amnon wrote: > But now it is out, I think it is great, and have run > perl -pi -e 's/for (\w+) := 0; \1 < ([\w()]+); \1\+\+/for \1 := range > \2/' $(git grep -l for) over my entire codebase to use it everywhere. > You know your own codebase, and maybe this wa

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

On Wed, Oct 11, 2023 at 11:31 PM Torsten Bronger < bron...@physik.rwth-aachen.de> wrote: > > 'Axel Wagner' via golang-nuts writes: > > > > > [...] > > > > > > What would this do? > > > > > > func F(s []any) { > > > s[0] = "Foo" > > > } > > > func main() { >

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

A quick correction to my own comment: On Sun, Oct 1, 2023 at 8:35 PM Patrick Smith wrote: > The problem with your code is that "T comparable" guarantees that two > values of type T can be compared, > ... but then I remembered the comparison can still panic at runtime, as per

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

On Sun, Oct 1, 2023 at 7:30 PM Jon Watte wrote: > I want to implement a generic function to "remove nil values from a > slice." This should be able to remove nil instances of error, for example. > So, let's say I have: > > var arg = []error{nil, errors.New("oh noes"), nil} > > Unfortunately, this

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

Actually, this example is a bit unfortunate. Depending on the implementation of append, the capacity of s3 may be small enough that a new buffer must be allocated for s4, which means there is no need to test for overlaps. https://go.dev/play/p/n5FNqlA0DaS demonstrates that this is what happens in t

Re: [go-nuts] Re: behavior of %f

On Mon, Oct 10, 2022 at 6:10 PM Patrick Smith wrote: > %g differs from %f when printing large or small values. > https://go.dev/play/p/lxj9fn19kOO > For the sake of completeness, I should add that they can also differ for "normal" sized values: https://go.dev/play/p/xiFwO

Re: [go-nuts] Re: behavior of %f

This program (https://go.dev/play/p/w-QE790dGcs) func main() { f := 0.999 fmt.Printf("%0.2f %0.3f %0.4f\n", f, f, f) fmt.Println(f) fmt.Printf("%0.64f\n", f) } prints 1.00 0.999 0.9990 0.999 0.99899911182158029987476766109466552734375000 The last line prints

Re: [go-nuts] Finding the go command from inside a test case

On Thu, Aug 11, 2022 at 3:19 AM ma...@eliasnaur.com wrote: > exec.LookPath is even better in Go 1.19, which implements > > "go test and go generate now place GOROOT/bin at the beginning of the PATH > used for the subprocess, so tests and generators that execute the go > command will resolve it to

[go-nuts] Finding the go command from inside a test case

I sometimes find that I want to run the go command from inside a test case, for example to build generated code, or to verify that code that should raise an error at compile time does in fact cause that error. That raises the question, is there a reliable way to find the go command from inside a t

Re: [go-nuts] IsNil check. How?

On Wed, Mar 16, 2022 at 3:25 PM Alex Besogonov wrote: > Note that in your case, the dynamic value of that interface *is not nil*. > It's a struct value. Structs can not be nil. > > Incorrect. Go language allows coercing a struct with an embedded pointer > to an interface. Spec: > "If S contains a

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

On Tue, Jan 19, 2021 at 7:06 PM burak serdar wrote: > However, there is no way for P to check if x is nil. This does not compile: > > func P[T fmt.Stringer](x T) { > if x!=nil { > fmt.Println(x) > } > } Is this doing what you want? func P[T fmt.Stringer](x T) { if fmt.St

Re: [go-nuts] Exec and write data to stdin of new process

Not a general solution, but if you are only writing a small amount of data, you can simply write it to the pipe and then exec the other program: https://play.golang.org/p/e0UQRE6SsT4 If I recall correctly, many years ago you would have been able to write 256 bytes this way. No doubt someone else c

Re: [go-nuts] Generics - type inference - which type parameters?

but U is considered to be a fixed type, not subject to type unification. On Mon, Aug 24, 2020 at 4:47 PM Ian Lance Taylor wrote: > On Mon, Aug 24, 2020 at 4:34 PM Patrick Smith > wrote: > > > > I may be missing something, but it seems to me that one point in the > draft&#

[go-nuts] Generics - type inference - which type parameters?

I may be missing something, but it seems to me that one point in the draft's discussion of type inference could usefully be clarified ( https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-inference ). The term "type parameter" there should be restricted

[go-nuts] [generics]: Pointer methods in interfaces used as constraints?

https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#pointer-method-example has this example: // Setter2 is a type constraint that requires that the type // implement a Set method that sets the value from a string, // and also requires that the type be a poin

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

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, > there is no sensible way to > do it with an in

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

Sorry, I accidentally sent the previous message before it was complete. Please ignore that one. On Tue, Aug 11, 2020 at 8:31 PM Ian Lance Taylor wrote: > To me the point of your String example is: Go already has various ways > of writing generic code. You can use interfaces, methods, and type >

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

On Tue, Aug 11, 2020 at 8:31 PM Ian Lance Taylor wrote: > To me the point of your String example is: Go already has various ways > of writing generic code. You can use interfaces, methods, and type > assertions. You can use reflection. The generics design draft adds > another way: parametric po

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

Ian, thanks for taking the time to read and respond to my post. On Sun, Aug 9, 2020 at 6:29 PM Ian Lance Taylor wrote: > If we accept this argument, then in Go it wouldn't be appropriate to > write a single function that works on both builtin and user-defined > types. This I disagree with; what

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

On Mon, Aug 10, 2020 at 1:53 PM burak serdar wrote: > Would it be possible to make it explicit instead of trying to combine > builtin types and others? > > type Number interface { >type int, int8, int16, int32, int64, unit, int8, int16, int32, > uint64, float32, float64 > } > > func Min(type T

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

On Mon, Aug 10, 2020 at 9:46 AM 'Richard Oudkerk' via golang-nuts wrote: > Another way to bridge the gap between builtin and custom types could be to > have a package op that has functions that delegate to either an operator or a > method. Then you could write generic functions like > > func Mi

[go-nuts] Generics: after type lists

I like the second draft for generics. It seems to me a large simplification and improvement over the first draft. Considering just the state of Go today, I would be quite happy with this, even if it's not perfect. Thanks to Ian, Robert, and everyone else for their work on this. Also, I would vote

Re: [go-nuts] Proposed changes to the Go draft generics design in the light of feedback received

On Fri, Oct 19, 2018 at 10:48 AM alanfo wrote: > In the light of all the feedback there's been, I've put together a > proposal which sticks closely to the original design and only changes what > most people consider needs to be changed in some way. Some recent ideas > which seemed plausible but w

Re: [go-nuts] Re: Generics: an unwelcome conclusion and a proposal

On Wed, Oct 17, 2018 at 3:13 AM alanfo wrote: > On Wednesday, October 17, 2018 at 12:22:15 AM UTC+1, Patrick Smith wrote: >> >> If overloading [] were disallowed, how would one write a generic function >> taking a single argument of type either []int or a user-defined

Re: [go-nuts] Re: Generics: an unwelcome conclusion and a proposal

Delete). The [] notation is just syntactic sugar for slice.At(). When used > as a left side, it is syntactic sugar for Set(). > > On Oct 16, 2018, at 6:21 PM, Patrick Smith wrote: > > On Tue, Oct 16, 2018 at 3:33 AM alanfo wrote: > >> I would also disallow overloading of the =

Re: [go-nuts] Re: Generics: an unwelcome conclusion and a proposal

On Tue, Oct 16, 2018 at 3:33 AM alanfo wrote: > I would also disallow overloading of the =, :=, <-, ..., [], {}, () and > yes - equality operators - as well because I believe to do otherwise would > be very confusing. > If overloading [] were disallowed, how would one write a generic function ta

Re: [go-nuts] Generics with adaptors

On Tue, Oct 16, 2018 at 3:21 PM Ian Denhardt wrote: > Quoting Patrick Smith (2018-10-16 18:04:05) > >One way to avoid this is to supply the adaptor when the Set is > created, > >store it in the Set, and thereafter used the stored adaptor instead of > >requir

Re: [go-nuts] Generics with adaptors

On Tue, Oct 16, 2018 at 12:01 PM Ian Denhardt wrote: > * We don't actually need an adaptor for the zero value, since we can > just declare a variable of the generic type: > > func MyFn(type T) { > // x is the zero value, per usual initialization rules: > var x T > True. Thi

Re: [go-nuts] Re: Generics with adaptors

On Tue, Oct 16, 2018 at 5:44 AM Eric Raymond wrote: > On Tuesday, October 16, 2018 at 6:34:10 AM UTC-4, Patrick Smith wrote: >> >> Yet another generics discussion at >> https://gist.github.com/pat42smith/ccf021193971f6de6fdb229d68215302 >> > > I think it fails Ia

[go-nuts] Generics with adaptors

Yet another generics discussion at https://gist.github.com/pat42smith/ccf021193971f6de6fdb229d68215302 This one looks at what programmers would be able to do if very basic generics were added to Go, without contracts. Generic functions may not use methods or operators of their type parameters. Th

[go-nuts] Generics a little bit of specialization

One way to allow generic functions to work on both built-in and user-defined types would be to add some specialized functions in the standard library. These would be like overloaded operators, but with function syntax instead of operator syntax. For example, we might have a package operators, conta

Re: [go-nuts] A simplified generics constraint system.

I think your idea of creating standard contracts to represent similar types is a good one. However, you don't have to say how those contracts are written, just what they do. No need for typecheck, union, except, etc. For example, Integer(T) - T is an integer type Float(T) - T is a floating point t

Re: [go-nuts] Why is go starting multiple child process?

I don't know about Ubuntu 16.04. On my Arch Linux system, 'pstree -V' shows "pstree (PSmisc) 23.1" On Sun, Sep 16, 2018 at 9:28 PM wrote: > There's no -T in Ubuntu 16.04, am I wrong? > > On Monday, September 17, 2018 at 11:54:05 AM UTC+8, Patrick Smith

Re: [go-nuts] Why is go starting multiple child process?

Probably those are threads, not processes. Try 'pstree -T'. Also, I believe the variable name is GOMAXPROCS, with an S at the end. On Sun, Sep 16, 2018 at 8:35 PM wrote: > package main > import ( > "log" > "time") > > func main () { > log.Println("sleep 30s") > time.Sleep(30 * ti

[go-nuts] Ambiguity in generic interfaces

(Apologies if this has already been brought up; I don't remember seeing it.) While writing a bit of sample generics code, I ran into a nasty little ambiguity: type Foo(type T) interface {} type Bar(type T) interface { Foo(T) } Does this embed the interface Foo(T) into Bar(T), or does it add t

Re: [go-nuts] Re: Generic types - functions and methods on instantions

On Wed, Sep 12, 2018 at 7:49 AM Ian Lance Taylor wrote: > On Tue, Sep 11, 2018 at 5:38 PM, Patrick Smith > wrote: > > First, please consider requiring the 'type' keyword in definitions of > > methods on generic types: > > > > func (x Foo(type T)) method(

Re: [go-nuts] Generics - Min challenge

On Wed, Sep 12, 2018 at 6:34 AM Ian Lance Taylor wrote: > That said, if we move forward with something like contracts, I think > that it may be possible to introduce contract adaptors in the future: > a mechanism that says "if the type argument does not implement > contract C1, but does implement

[go-nuts] Generics - Min challenge

This is a hypothetical question. Suppose generics were implemented as in the draft proposal, but without contracts. Instead, the rule is that if an instantiation of a generic function with a specific type argument doesn't compile, then it can't be used. Under those circumstances, is there any way

Re: [go-nuts] Re: Generic types - functions and methods on instantions

On Tue, Sep 11, 2018 at 6:56 AM wrote: > 2. An initialized type cannot be used directly as a method receiver, it > must be type-aliased first: > type FooInt = Foo(int) > func (fi FooInt) Bar() {} // no type parameters now so clearly a > method of FooInt > ... > Another problem is whether

Re: [go-nuts] Re: Generic types - functions and methods on instantions

On Tue, Sep 11, 2018 at 10:45 AM Ian Lance Taylor wrote: > On Tue, Sep 11, 2018 at 10:04 AM, roger peppe wrote: > >> func (x Foo(int)) Bar() {} > > > > As I understand it, this would be technically allowed, but would not > > mean what you think. > > Yes. > Ouch! I chose a poor example. I think

[go-nuts] Generic types - functions and methods on instantions

Under the generics draft, would this be allowed? type Foo(type T) struct{} func f(x Foo(int)) {} I assume the answer is yes; I can't see any good reason to disallow it. What about this? func (x Foo(int)) Bar() {} If this is allowed, does this now mean that Foo(int) implements type Barrable

Re: [go-nuts] Struct literal in condition of if statement yields compile error

On Tue, Feb 6, 2018 at 1:37 PM, Jan Mercl <0xj...@gmail.com> wrote: > > Not a bug. See https://golang.org/ref/spec#Composite_literals > > > > A parsing ambiguity arises when a composite literal using the TypeName > form of the LiteralType appears as an operand between the keyword >

[go-nuts] Struct literal in condition of if statement yields compile error

See https://play.golang.org/p/cO4LQFk7ew- Given a struct definition type S struct { a, b int } an if statement of the form if x == S{ 0, 1 } { ... } yields compile errors such as prog.go:19:18: syntax error: unexpected }, expecting := or = or comma prog.go:22:1: syntax error: non-declaration

Re: [go-nuts] Re: os.remove is slow

Does it make a difference if you first change directory to /var/spool/directory, then glob * and unlink the resulting filenames, without prepending the directory? On Mon, Dec 4, 2017 at 11:05 AM, Gabriel Forster wrote: > Readdirnames wasn't much better. Now using globbing and syscall.Unlink > wh

Re: [go-nuts] Why isn't golang input and output is buffered?

That is simpler, but slower. Not nearly as slow as using unbuffered io though. Timings on my machine, reading 1e6 integers chosen randomly from the range [0,1e18): Original code https://play.golang.org/p/grB-muK7hw 5.626974435s 155.367779ms Original poster's optimized code https://play.golang.org

Re: [go-nuts] Index operator on pointer to array or slice

to a slice is much less so; in > fact, it's often a mistake. The slice already contains a pointer to the > data (in fact, as a pointer to an array!). Best not to promote the bad idea. > > -rob > > > On Sun, Dec 4, 2016 at 11:27 AM, Patrick Smith > wrote: > >>

[go-nuts] Index operator on pointer to array or slice

The spec says: "A primary expression of the form a[x] denotes the element of the array, pointer to array, slice, string or map a indexed by x." I am curious about one point - what is the reason for allowing a to be a pointer to array, but not allowing a to be a pointer to slice? In both case

Re: [go-nuts] image: algorithm to convert to grayscale

Looks like it's just rounding to the nearest integer. On Wed, Sep 28, 2016 at 3:19 PM, Rodolfo Carvalho wrote: > Hello, > > I'm not an image processing expert, but was trying to write a small > program to convert images to grayscale, just for the fun of it [1]. > > First I managed to get somethi

[go-nuts] overflow bugs in bytes.Repeat, strings.Repeat

Seeing the discussion of strings.Repeat and invalid inputs in another thread, I noticed a couple of bugs. One I have reported - https://github.com/golang/go/issues/16237 The other I'm not sure if it's worth a report. Here's the source for bytes.repeat: 391 func Repeat(b []byte, count int) []b