Re: [go-nuts] Nillable basic types?

[Mike Schinkel]

> On Mar 19, 2024, at 2:43 PM, 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 | nil` would be larger. 
> Existing code, which obviously doesn't use the `| nil` syntax because it 
> doesn't exist yet, would be completely unaffected by this change.

Focusing the proposal like that was helpful, at least for me.  The original 
proposal? tldr; 

Question: Assuming the following was currently possible with type constraints, 
how would your proposal differ from the following?

type NillableUInt8 interface {
   uint8 | nil 
}
var x NillableUInt8

Also, if the above were possible in future Go, would that achieve the same 
objectives you are seeking, or not?  And if not, why not?

Finally, for the Go team, if that would be meet his objectives, would extending 
type constraints in this manner be a viable potential?

-Mike

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/3CC3FD1B-D591-4B21-AE7B-0D9E5C821F31%40newclarity.net.

Re: [go-nuts] Nillable basic types?

['Brian Candler' via golang-nuts]

When you say "var x NillableUint8" then you've just declared a variable of 
an interface type, and interface types are already nilable, so there's no 
need for "| nil" in the type!

https://go.dev/play/p/f54akG65qJ3
https://go.dev/play/p/Jmtlta0h9m9   // generic version

It's a perfectly valid way of specifying an optional value ("error" works 
this way, after all). However, I don't think this meets the OP's  objective 
number 3:

> 3. It is a compile-time error to use a `T | nil` as a `T` without first 
checking that it is non-nil.

Therefore I think the underlying request a completely different one: that 
you should never be able to use an interface (or a pointer or a channel, or 
insert into a map), without first checking that it's not nil, in a way that 
can be statically validated by the compiler. I'm sure that suggestion has 
come up before and been discussed to death - e.g. you end up with static 
types like "a pointer which can never be nil".

On Wednesday 20 March 2024 at 07:34:10 UTC Mike Schinkel wrote:

> On Mar 19, 2024, at 2:43 PM, 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 | nil` would be larger. 
> Existing code, which obviously doesn't use the `| nil` syntax because it 
> doesn't exist yet, would be completely unaffected by this change.
>
>
> Focusing the proposal like that was helpful, at least for me.  The 
> original proposal? tldr; 
>
> Question: Assuming the following was currently possible with type 
> constraints, how would your proposal differ from the following?
>
> type NillableUInt8 interface {
>
>uint8 | nil 
>
> }
>
> var x NillableUInt8
>
>
> Also, if the above were possible in future Go, would that achieve the same 
> objectives you are seeking, or not?  And if not, why not?
>
> Finally, for the Go team, if that would be meet his objectives, would 
> extending type constraints in this manner be a viable potential?
>
>
> -Mike
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/9e78e0c1-81cc-46c0-87ac-5bfd183093aen%40googlegroups.com.

Re: [go-nuts] Using new variable or updating existing variable in a loop

[Mohamad Rostami]

Thanks @kurtis, 
I actually have both functions without fmt print function, so no allocation 
is happening. 
I also did compare assembly codes with your command, and can confirm both 
are equal. 
go 1.21.0 darwin/arm64




On Tuesday, March 19, 2024 at 11:20:03 PM UTC+1 Kurtis Rader wrote:

> 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: ... argument does not escape
>
> The issue isn't that the stack is growing. The issue is the `h := h` 
> assignment in B() is causing a new heap allocation each time through the 
> loop. I don't know why either var definition is escaping to the heap but 
> the increasing address for the B() case is because you're making 1e5 
> instances of that heap var.
>
> On Tue, Mar 19, 2024 at 1:12 PM Mohamad Rostami  
> wrote:
>
>> 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)
>>}
>> }
>>
>> //go:noinline
>> func B() {
>>for i := 0; i < 1e5; i++ {
>>  h := i
>>  _ = h
>>  fmt.Printf("%+v\n", &h)
>>}
>> }
>>
>> The address of h in B is changing in each iteration although it's not 
>> causing stack to grow. 
>>
>> If you point me to the documentation for this specific case, I would 
>> appreciate it. 
>> Regards,
>>
>> On Tuesday, March 19, 2024 at 5:46:36 PM UTC+1 Ian Lance Taylor wrote:
>>
>>> 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 didn't find any 
>>> performance related differences, but in terms of Stack Memory in use, the 
>>> second approach is better than the first one. 
>>> > 
>>> > Not sure if the way is in standard library is by intention or 
>>> something that should be ignored. 
>>>
>>> The two versions are basically equivalent. How are you measuring 
>>> stack memory usage? If they are different, there may be something to 
>>> fix in the compiler. 
>>>
>>> Ian 
>>>
>> -- 
>>
> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/3818a025-d46c-4e23-8b2e-6e0a08c0986an%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/c69c276b-ae46-4649-b5bb-3204e7362735n%40googlegroups.com.

Re: [go-nuts] Nillable basic types?

[Mike Schinkel]

On Wednesday, March 20, 2024 at 4:14:27 AM UTC-4 Brian Candler wrote:

When you say "var x NillableUint8" then you've just declared a variable of 
an interface type, and interface types are already nilable, so there's no 
need for "| nil" in the type!


Well, I was thinking  of 1.) explicitness of intent, and 2.) potentially a 
signal to the compiler for the use-case.  

But you probably have a point.
 

However, I don't think this meets the OP's  objective number 3:

> 3. It is a compile-time error to use a `T | nil` as a `T` without first 
checking that it is non-nil.


Hmm.  While I did not read the whole proposal at first, my initial takeaway 
was that his intent was more about allowing a way for a scalar value to 
have an invalid value so it would be possible to determine if a scalar had 
been set or not rather than being unsure if zero means *"It was set to 0"* 
vs *"It was never set and defaulted to 0."*

Your comments made me go back and read the whole thing, but I was unable to 
find a list of enumerated objectives, and I did not find the text you 
quoted.  Did I miss it somehow?

What I did see is his *"Nice to have"* section which talked about checking 
for non-nil.  Since he titled it *"nice to have"* I presume he did not 
consider that a primary objective of his proposal?

OTOH, even if it is an explicit call-out of `nil` in a type constraint 
*could* be the signal for the compiler to enforce that, if that was 
something the Go team agreed with that. Still, it is probably too obscure 
to be an appropriate signal. ¯\_(ツ)_/¯

Therefore I think the underlying request a completely different one: that 
you should never be able to use an interface (or a pointer or a channel, or 
insert into a map), without first checking that it's not nil, in a way that 
can be statically validated by the compiler. I'm sure that suggestion has 
come up before and been discussed to death - e.g. you end up with static 
types like "a pointer which can never be nil".


I definitely see there is an argument one could make for having the 
compiler guarantee against incorrectly using `nil`.  But I got the 
impression the proposal was motivated by scalars that did not currently 
allow `nil` values and not by reference types like pointers, channels and 
maps. Although he did not state that explicitly, his examples implied that 
to me.

For the compiler to guarantee that an `int` is properly set it needs as a 
prerequisite the potential for what it effectively a `nil` state. But 
ensuring against a misused `nil` feels to me to be orthogonal to first 
allowing an *"unset"* state for scalars.  

Or maybe I misread?  Maybe the best thing to do is let him tell us what he 
was thinking?
 
-Mike


On Wednesday 20 March 2024 at 07:34:10 UTC Mike Schinkel wrote:

On Mar 19, 2024, at 2:43 PM, 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 | nil` would be larger. 
Existing code, which obviously doesn't use the `| nil` syntax because it 
doesn't exist yet, would be completely unaffected by this change.


Focusing the proposal like that was helpful, at least for me.  The original 
proposal? tldr; 

Question: Assuming the following was currently possible with type 
constraints, how would your proposal differ from the following?

type NillableUInt8 interface {

   uint8 | nil 

}

var x NillableUInt8


Also, if the above were possible in future Go, would that achieve the same 
objectives you are seeking, or not?  And if not, why not?

Finally, for the Go team, if that would be meet his objectives, would 
extending type constraints in this manner be a viable potential?


-Mike

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/66a9f1f6-a05d-4fed-b41d-5cfec262fb5bn%40googlegroups.com.

Re: [go-nuts] Nillable basic types?

['Brian Candler' via golang-nuts]

On Wednesday 20 March 2024 at 09:01:43 UTC Mike Schinkel wrote:

Your comments made me go back and read the whole thing, but I was unable to 
find a list of enumerated objectives, and I did not find the text you 
quoted.  Did I miss it somehow?


It's in the very first post that opened this thread, under the heading "## 
Summary". This link should take you to it:
https://groups.google.com/g/golang-nuts/c/pN0AO7a_S2k/m/3osyz_NyBgAJ

Quoting directly:

# Proposal: Nillable types

## Summary

I propose that for any type T, the type `T | nil` should also be a valid 
type with the following properties:
1. The zero value of a `T | nil` is `nil`.
2. Any `T` or `nil` may be used as a value of `T | nil`
3. It is a compile-time error to use a `T | nil` as a `T` without first 
checking that it is non-nil.

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/51fec468-faa5-4a42-b10a-31fa68f1a9c3n%40googlegroups.com.

Re: [go-nuts] Nillable basic types?

['Brian Candler' via golang-nuts]

I got the impression the proposal was motivated by scalars that did not 
currently allow `nil` values


Under the heading "Alternatives and why they're bad" he describes some ways 
this is currently dealt with - such as the common idiom of returning or 
passing a pointer to a value, instead of a plain value.  (He didn't mention 
using an interface, incidentally - which doesn't have some of the downsides 
he described. For example, a plain numeric value wrapped in an interface 
can't be mutated)

As has already been observed, if you're going to allow the full range of 
values of some type T (i.e. all possible bit patterns), *plus* the sentinel 
value of "unset", then you need an extra bit - which can be done using a 
struct, or by indirecting through a pointer or an interface. 

The problem that the OP has is that none of those options will force you to 
check the state of the extra bit, or that the pointer/interface is not nil 
- which could be argued is a problem with pointers/interfaces in general.

But I think this is not really worth arguing. If you change fundamental 
things like this in the language, then you'll suggesting turning Go into 
something that looks like Rust. In which case, you may as well just use 
Rust.

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/b409e7bb-ef94-40db-986f-268643e7cb39n%40googlegroups.com.

Re: [go-nuts] Nillable basic types?

[Mike Schinkel]

On Wednesday, March 20, 2024 at 5:31:08 AM UTC-4 Brian Candler wrote:


It's in the very first post that opened this thread, under the heading "## 
Summary".


I did in-fact miss it. Thank you for pointing to it.

-Mike 
 

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/7e807f38-97a2-4890-9a9b-bd0e535e481bn%40googlegroups.com.

Re: [go-nuts] Nillable basic types?

[Mike Schinkel]

On Wednesday, March 20, 2024 at 5:47:00 AM UTC-4 Brian Candler wrote:

If you change fundamental things like this in the language, then you'll 
suggesting turning Go into something that looks like Rust. In which case, 
you may as well just use Rust.


Agreed.  Which is why I was asking if using interfaces as type constraints 
would address the concern.

And as discussed, probably not.  

But it is an interesting thought exercise. If an interface-based solution 
could be found, it would address the concern without turning us effectively 
into Rust programmers. ¯\_(ツ)_/¯ 

-Mike

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/b3cf8686-b0fb-4cdd-938e-deee4a6af273n%40googlegroups.com.

Re: [go-nuts] Nillable basic types?

['Axel Wagner' via golang-nuts]

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 - you'd have to use a type-assertion to use an `interface{ int }`
as an integer (e.g. to do arithmetic), you can use it with type-switches,
and any `int` as well as `nil` would be assignable to it.

I think the one difference would be that `x == 42` would work on
`interface{ int }`, but would (presumably) not work on `int | nil`. I
personally doubt that this difference would justify an extra construction,
but I'm mentioning it for completeness sake.

The "nice to have" of type guards is, I think, an easy idea to mention, but
not an easy idea to add to Go. Note that the other languages mentioned,
that do that, use a function-scoped type-inference (as far as I know) -
that is, they look at an identifiers use over the entire function and then
infer the most general type it would have.
Go has so far tried to avoid doing anything like that, limiting any
inference to the statement (or expression) a value appears in. And this
idea effectively means an identifier would change its type over its
lifetime (from `interface{ int }` - does not allow arithmetic - to `int` -
does allow arithmetic), which would create numerous problems for existing
tooling, as it violates assumptions made by the `go/*` packages.

On Wed, Mar 20, 2024 at 11:26 AM Mike Schinkel  wrote:

> On Wednesday, March 20, 2024 at 5:47:00 AM UTC-4 Brian Candler wrote:
>
> If you change fundamental things like this in the language, then you'll
> suggesting turning Go into something that looks like Rust. In which case,
> you may as well just use Rust.
>
>
> Agreed.  Which is why I was asking if using interfaces as type constraints
> would address the concern.
>
> And as discussed, probably not.
>
> But it is an interesting thought exercise. If an interface-based solution
> could be found, it would address the concern without turning us effectively
> into Rust programmers. ¯\_(ツ)_/¯
>
> -Mike
>
> --
> 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
> https://groups.google.com/d/msgid/golang-nuts/b3cf8686-b0fb-4cdd-938e-deee4a6af273n%40googlegroups.com
> 
> .
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHkUwS_XyNAkwM79Hy4F_%2BQxy%3DcaZRvmYkCc-MDi3O9Ww%40mail.gmail.com.

Re: [go-nuts] Re: 'go run hello.go' taking ~30 seconds on windows

[Larry Clapp]

I found this webpage from MS which talks about configuring Windows Defender.

https://support.microsoft.com/en-us/windows/turn-off-defender-antivirus-protection-in-windows-security-99e6004f-c54c-8509-773c-a4d776b77960

I'm running a Windows 10 VM via VirtualBox on a MacBookPro. I have my $HOME 
(where I have all my source code) imported into the VM as the E: drive in 
the VM. Reading the above and poking around a bit led me to a) exclude the 
E: drive "folder", and b) exclude the "go.exe" executable.

"go test" time dropped from > 3m to ~6s.

Hope that helps.

-- Larry


On Thursday, June 22, 2023 at 8:47:59 AM UTC-4 Jet Li wrote:

Like to note that if you mean Windows Defender, there is no way to disable 
that after Build 20H2 iirc where I was task to deploy Windows 10 and could 
not find the option in Windows Group Policy settings after the update, if 
Go app are affected by Windows Defender. Your only option is to use older 
Windows build and alternative OS, mileage may vary.

Another option, could be impossible to backup VM image as it's on macOS
https://multipass.run/
On Thursday, 22 June 2023 at 19:52:56 UTC+8 Wojciech S. Czarnecki wrote:

> Hello, 
> 
> Was there a solution to this? I am having the same issue. Win 10 machine 
> and compiling and running simple lines of code takes ages. 

The answer is always the same: turn off your antivirus software for your 
development tree. 

Such delays are due to "heuristics" usually implemented by uploading your 
exe to the vendor. 
Root cause is that after 12 years AV vendors still can not cope with what 
they pereceive 
a "non standard" linker, ie. a Go's one. 

hope this helps, 

-- 
Wojciech S. Czarnecki 
<< ^oo^ >> OHIR-RIPE 

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/d48865a7-6017-4edb-b94c-550afa8ca280n%40googlegroups.com.