spec: new(expr) should allow "untyped bool values" too

[mdempsky]

The Go spec says:

If the argument expr is an expression of type T, or an untyped constant expression whose default type is T, then new(expr) allocates a variable of type T, initializes it to the value of expr, and returns its address, a value of type *T.

But https://go.dev/play/p/2YcYIT0uTTi?v=gotip accepts this code:

func main() {
	var i int
	fmt.Printf("%T\n", new(i == i))
}

Note: The comparison here is an untyped boolean value, but not an untyped constant.

For comparison, variable declarations says:

If a type is present, each variable is given that type. Otherwise, each variable is given the type of the corresponding initialization value in the assignment. If that value is an untyped constant, it is first implicitly converted to its default type; if it is an untyped boolean value, it is first implicitly converted to type bool.

I think similar text is needed to describe the above compiler behavior.

Or the compiler should be made to reject it, but I think that's less desirable.

(Glad to see this feature finally implemented!)

/cc @alandonovan @griesemer @findleyr

[gabyhelp]

Related Issues

• spec: clarify assignability for non-constant untyped boolean values #15171
• spec: result of comparison should always be untyped bool #4793 (closed)
• spec: expression to create pointer to simple types #45624 (closed)
• proposal: spec: drop new(int) in favor of &int{} #20446 (closed)
• cmd/gc: result of comparison should be untyped boolean #3915 (closed)
• spec: determine when bool is ideal bool #2561 (closed)
• proposal: spec: add &T(v) to allocate variable of type T, set to v, and return address #9097 (closed)
• go/types: "var x, y b = i.(b)" should declare 'y' with type 'b', not 'bool' #15755 (closed)
• cmd/gc: result of comparison should be comparable to any boolean type #3923 (closed)

Related Code Changes

• cmd/compile: fix ICE with new(<untyped expr>)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[griesemer]

Hi Matt; thanks for pointing this out.

I was actually aware of this when I worked on the most recent CL fixing a bunch of issues with new(x), and tried to do the right thing in the implementation, but obviously missed the necessary spec change.

Will fix.

(I consider this a documentation mistake, not a new change. I think the intention from the start was that this should work.)

[thediveo]

iirc then not least the Docker api has tri-state bools using *bool in some places, so support for new(true) world be very welcome.

[zigo101]

I don't know whether or not the following should compile, just a mention.

package main

import "fmt"

func main() {
	var i int = 8
	var n byte = 1 << i
	fmt.Printf("%v\n", n)
	
	var p *byte = new(1 << i) // not compile on tip
	fmt.Printf("%v\n", *p)
}

[adonovan]

It's working as intended that you'll get this error:

cannot use new(1 << i) (value of type *int) as *byte value in variable declaration

That's because the type of 1<<i is int. Types don't flow uphill from function result types to function parameters.

[zigo101]

... because the type of 1<<i is int ...

This might be not always true. For example, var n byte = 1 << i compiles.

[adonovan]

... because the type of 1<<i is int ...

This might be not always true. For example, var n byte = 1 << i compiles.

Shifts are one of the rare places in the spec where types do flow uphill from the LHS of the assignment to the RHS. But this never happens through function calls.

[TapirLiu]

I'm just not sure if the same concern also applies here too.

[TapirLiu]

BTW, what is the concern for the behavior of UntypedInt << NonConstantInt?