Oleksii Shnyra
Oleksii Shnyra

Reputation: 691

Why to use "redundant" keyword "struct" for types in Go?

I am a big fan of Golang, and very pleased to how the syntax of Go is designed. As a part of syntax philosophy, we have a rule as following: omit the things (keywords, characters etc.) if they are not needed actually.

For that reason instead of writing redundant colons:

for ; sum < 1000; {
    sum += sum
}

You allowed to simply put:

for sum < 1000 {
    sum += sum
}

notice how we omitted redundant semicolons

And there are lots of other cases where syntax is gratefully simplified.

But what about struct when we define type?

type Person struct {
    name string
}

Why do we need to put struct keyword here? Keywords are to determine intention, to clarify the exact choice of available options so a compiler knows how to do his job properly.

Will it be unclear and ambiguous if we simply put:

type Person {
    name string
}

??

I believe there is a meaning for struct in the examples above because compiler fails when type defined without struct keyword.

Please, explain me (and provide links) what else we can use instead of struct when we define some type.

Please, list available options from which we want to clarify to a compiler that things in curly brackets after type name are exactly parts of a struct and not something else (what else?).

Thanks.

Upvotes: 2

Views: 1665

Answers (2)

icza
icza

Reputation: 418435

Types (may) not only appear in type declarations, but in countless other places, for example in function declarations.

Structs may be "used" anonymously, without creating a named type for them. For example, the following declaration is valid:

func GetPoint() struct{ x, y int } {
    return struct{ x, y int }{1, 2}
}

Without having to use the struct keyword, a parsing ambiguity would arise in multiple uses. Let's say we want to create a function which returns an empty struct:

func GetEmpty() struct{} {
    return struct{}{}
}

How would this look like without the struct keyword?

func GetEmpty2() {} {
    return {}{}
}

Now if you're the compiler, what would you make out of this? Is this a function with the same signature as GetEmpty()? Or is this a function without a return value and an empty body (func GetEmpty2() {}) followed by a block which contains a return statement? The return statement would be another ambiguity, as it may return nothing which is followed by 2 empty blocks, or it may return an empty struct value which is followed by an empty block...

Now to avoid parsing ambiguity, we have to use the struct keyword when specifying struct types elsewhere (outside of type declarations), then why make it optional or disallow it in type declarations?
I think a consistent syntax is more important than grabbing all chances to reduce the language (syntax) to the minimum possible. That hurts readability big time. The for loop example you mentioned is not really a simplification, but rather the usage of different forms of the for loop.

Upvotes: 2

Adrian
Adrian

Reputation: 46562

It's not redundant. You can make types from existing types:

type MyType int
type MyType string

Or interfaces:

type Stringer interface {
    String() string
}

This is covered in the Go tour and in the spec.

Upvotes: 5

Related Questions