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

proposal: Go 2: make struct keyword inherent #41928

Closed
ivanjaros opened this issue Oct 12, 2020 · 11 comments
Closed

proposal: Go 2: make struct keyword inherent #41928

ivanjaros opened this issue Oct 12, 2020 · 11 comments

Comments

@ivanjaros
Copy link

@ivanjaros ivanjaros commented Oct 12, 2020

Whenever you are defining a new type that is a struct the syntax is as follows:

type Foo struct {
  Bar string
  Baz int
}

Since there is no other use case where the type definition is enclosed in curly brackets(= struct-ure) the type keyword should be sufficient to imply struct, hence the struct keywords seems unnecessary.

type Foo {
  Bar string
  Baz int
}
@gopherbot gopherbot added this to the Proposal milestone Oct 12, 2020
@gopherbot gopherbot added the Proposal label Oct 12, 2020
@davecheney
Copy link
Contributor

@davecheney davecheney commented Oct 12, 2020

But why? Apart from changing something that hasn’t yet been changed, what does this accomplish?

@davecheney
Copy link
Contributor

@davecheney davecheney commented Oct 12, 2020

Also, don’t forget structs appear in other contexts,

func foo(s struct { a, b int })

Your proposal would introduce inconsistency.

@ivanjaros
Copy link
Author

@ivanjaros ivanjaros commented Oct 12, 2020

Why? Less code to write, less code to parse and compile, less source code to distribute.

It's like i := 5 vs var i int = 5. It's optional, yet 99% people use the first variant because it requires less typing(excluding cases for different types like var i in32 = 5). As for your example, it can be removed there as well, again with type definition the {} block implies structure so there is no context lost and the struct keywords is redundant. This does not break the backwards compatibility, it is optional.

@davecheney
Copy link
Contributor

@davecheney davecheney commented Oct 12, 2020

But why add something optional? What purpose does it serve to allow two ways to write something which was previous unambiguous?

@ivanjaros
Copy link
Author

@ivanjaros ivanjaros commented Oct 12, 2020

type MyDigit int <-- just int, one single type indicator
type MyObject sruct{} <-- two indicators, the {} itself indicates structure, hence struct keyword is redundant

it is not about adding, it is about removing.

using struct {} is like saying mark M12 where the M already represents mark/model. it is redundant.

@davecheney
Copy link
Contributor

@davecheney davecheney commented Oct 12, 2020

it is not about adding, it is about removing

Respectfully, my concern is that you are not removing anything, you are adding the ability for it to be optional. This creates confusion for the reader who must accomodate both styles.

@martisch martisch changed the title proposal: make struct keyword inherent proposal: Go 2: make struct keyword inherent Oct 12, 2020
@martisch martisch modified the milestones: Proposal, Go 2 Oct 12, 2020
@arturkuznetsou
Copy link

@arturkuznetsou arturkuznetsou commented Oct 12, 2020

Since there is no other use case where the type definition is enclosed in curly brackets(= struct-ure) the type keyword should be sufficient to imply struct, hence the struct keywords seems unnecessary.

what about type Foo interface{}?

@mvdan
Copy link
Member

@mvdan mvdan commented Oct 12, 2020

This would also hurt consistency; Go developers would now have to decide and agree on which of the two forms should be used for declaring structs. And, given the massive amount of Go out there using the current form, the new form could realistically never be used in a consistent way.

@ivanjaros
Copy link
Author

@ivanjaros ivanjaros commented Oct 12, 2020

what about type Foo interface{}?
nothing, it stays the same

@mvdan if we are talking about gofmt then i get your point and essentially it puts the stop to this conversation. which is fine with me.

but it also shows that we are inherently stuck with gofmt for ever since any change will break the backward compatibility one way or the other, without transitional reformatting of old code. it is one thing to only add things to the language(ie. generics) without breaking old code, but it is another if there is no way to remove/change something in its form(atter). just food for though.

@ivanjaros ivanjaros closed this Oct 12, 2020
@fzipp
Copy link
Contributor

@fzipp fzipp commented Oct 12, 2020

func foo() {}

Is this a function without return value or ist this a stub for a function that returns an empty struct and is implemented in assembly language?

See https://golang.org/ref/spec#Function_declarations
"A function declaration may omit the body. Such a declaration provides the signature for a function implemented outside Go, such as an assembly routine."

func flushICache(begin, end uintptr)  // implemented externally
@ivanjaros
Copy link
Author

@ivanjaros ivanjaros commented Oct 12, 2020

that's a return statement, not type definition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.