Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

proposal: all custom defined basic types should support composite literals #22677

Closed
dotaheor opened this issue Nov 12, 2017 · 5 comments
Closed

proposal: all custom defined basic types should support composite literals #22677

dotaheor opened this issue Nov 12, 2017 · 5 comments
Labels
FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change
Milestone
Proposal

Comments

@dotaheor
Copy link

dotaheor commented Nov 12, 2017 •
edited

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.
@gopherbot gopherbot added this to the Proposal milestone Nov 12, 2017
@mvdan mvdan added v2 A language change or incompatible library change LanguageChange labels Nov 12, 2017
@mvdan
Copy link
Member

mvdan commented Nov 12, 2017

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
Copy link
Contributor

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

@dotaheor
Copy link
Author

@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
Copy link
Member

dsnet commented Nov 13, 2017

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
Copy link
Contributor

andlabs commented Jan 18, 2018

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

@golang golang locked and limited conversation to collaborators Jan 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change
Projects
None yet
Milestone
Proposal
Development

No branches or pull requests
6 participants
@bradfitz @andlabs @mvdan @dsnet @gopherbot @dotaheor