On Wed, Mar 20, 2024 at 2:13 PM Ian Lance Taylor wrote:
> Some earlier discussions:
>
> https://groups.google.com/g/golang-nuts/c/b78eRMOS0FA/m/jq8lAQhenaoJ
> https://groups.google.com/g/golang-nuts/c/WGYJx3ICCW4/m/1L0WcN8eqmkJ
>
> See in particular this message from Russ:
> https://groups.google.
On Tue, Mar 19, 2024 at 6:40 PM Nigel Tao wrote:
>
> The ubiquitous io.Reader interface's Read method returns a (int,
> error). Surprisingly (for programmers coming from other languages with
> a built-in or idiomatic Result type), it's possible for both
> return values to be non-zero. There's (oft
The ubiquitous io.Reader interface's Read method returns a (int,
error). Surprisingly (for programmers coming from other languages with
a built-in or idiomatic Result type), it's possible for both
return values to be non-zero. There's (often overlooked??) commentary
in https://pkg.go.dev/io#Reader
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 |
Also, if you tell the compiler to report memory allocations you'll see
something like this:
./x.go:10:13: inlining call to fmt.Printf
./x.go:18:13: inlining call to fmt.Printf
./x.go:7:6: moved to heap: h
./x.go:10:13: ... argument does not escape
./x.go:17:3: moved to heap: h
./x.go:18:13: ... ar
I would start by building it with inlining disabled and assembler output
enabled. Then compare the assembly code for main.A and main.B.
go build -gcflags 'all=-l -S' x.go 2>y
On Tue, Mar 19, 2024 at 1:12 PM Mohamad Rostami
wrote:
> Well, I used runtime runtime.MemStats StackInuse.
> I don't hav
Well, I used runtime runtime.MemStats StackInuse.
I don't have much knowledge about compiler optimization.
But to make it clear for myself:
considering these 2 functions:
//go:noinline
func A() {
var h int
for i := 0; i < 1e5; i++ {
h = i
_ = h
fmt.Printf("%+v\n", &h)
}
*From Jan Mercl: *
> To represent all those values and the new possibility
> of the value being nil, we need 257 distinct values. But that does not
> fit 8 in bits anymore. However, changing the size and/or the bit
> representation of such a variable is observable, making it not
> backwards-compat
On Tue, Mar 19, 2024 at 9:36 AM Mohamad Rostami wrote:
>
> I've seen in many places in go source code re-declaring a variable with the
> same name.
> e.g:
> for i < j {
>h := ...
> }
> Instead of
> var h int
> for i < j {
>h = ...
> }
>
> So I did a benchmark to check the differences. I d
Hi,
I've seen in many places in go source code re-declaring a variable with the
same name.
e.g:
for i < j {
h := ...
}
Instead of
var h int
for i < j {
h = ...
}
So I did a benchmark to check the differences. I didn't find any
performance related differences, but in terms of Stack Mem
I understand the problem you are trying to solve, and it's valid, I think.
But this solutions "feels" bad and very un-Go-like. Usable zero values is
a feature in Go. Whether you agree with that or not, it's a selling feature
of the language and clearly something that was/is important to the Go
11 matches
Mail list logo
