proposal: all custom defined basic types should support composite literals

[dotaheor]

Often, I change the kinds of some custom types in my custom packages between non-basic types and basic types, back and forth. For example, one custom type declaration:

type MyType struct {
	a, b uint32
}

There are many local variables of this type are used in other packages.
These variables are declared like v := MyType{}

Later, I changed my mind to declare the type as

type MyType uint64

Now, all the variable uses are broken, for the error invalid type for composite literal.

However, if basic types also support composite literals. Those uses will be still legal.
And the proposal will make Go syntax more consistent.

[mvdan]

Large changes to the language won't happen in Go1, so labeling as Go2.

Note that both struct and basic types support var v T. If you used that, you wouldn't run into this problem.

The only cases where var v T and v := T{} would differ is in slices and maps, since the former would give nil and the latter would give empty, but non-nil.

[bradfitz]

Dup of #22647 and/or #19966, so closing this one.

[dotaheor]

@bradfitz It is not the same. The other two are proposed to take addresses of other values.
However, this proposal is to allow composite literals for basic types.

[dsnet]

I agree this is not the same, but I don't see the need for this to be a language change.

If the type was exported, you would not be able to change type since that would be a breaking change.
If the type was not exported, it seems that this a problem better suited for a static analysis tool to do the cleanup for you and not a language level change.

[andlabs]

@dotaheor but the issue both refer to, #9097, is =P