Go: proposal: compact syntax for multiple property assignation on a same object.

Created on 12 Nov 2019  路  14Comments  路  Source: golang/go

Hello,

In order to make assignation more DRY, it would be great to have something like that :

type FooStruct struct {
  ID string
  Name string
}

var res FooStruct

res.(
  ID = "12345"
  Name = "Foo"
)

// To replace
res.ID = "123456"
res.Name = "Foo"

Syntax should obviously be enhanced, but just an idea.

Go2 LanguageChange Proposal Proposal-FinalCommentPeriod dotdotdot

Most helpful comment

The second possibility above leads to a natural variant of the = operator, by analogy to the existing +=, >>=, &^=, [鈥 variants:

    x.SomeDescriptiveFieldName ...= {
        ID: "1234",
        Name: "Foo",    
    }

could be a shorthand notation for

    x.SomeDescriptiveFieldName = x.SomeDescriptiveFieldName...{
        ID: "1234",
        Name: "Foo",    
    }

All 14 comments

Today you can already write

    res = FooStruct{
        ID:   "12345",
        Name: "Foo",
    }

No I don't want to declare struct and properties in a concise way. But really group assignation in order to remove res. each time.

Given this state :

type Foo struct {
   ID string 
   Name string
   Bar string
   Whatever uint64
}
res := Foo{
   Name: "bar"
}

Applying this

res.{
  ID = "1234",
  Name = "Foo",
}

Is an alias of this : #SyntacticSugar

res.ID = "123456"
res.Name = "Foo"

It is like accessing the struct properties by key/value. Like you could do in JS for example.

This does not seem like it is worth modifying the language for. The assignments you want to replace are fine as is. DRY is IMO overkill when the thing you are repeating is the text of a single variable.

This proposal does not have much support according to emoji votes. As @randall77 says the only repetition saved is relatively small. For these reasons, this is a likely decline. Leaving open for four weeks for final comments.

~If Go had immutable types/values something like this would be needed. Without those, it might be nice in some situations (like simulating immutability), but probably not enough to be worth the change.~

@jimmyfrasche Do you mean "would be needed" or "would not be needed"? I'm not quite seeing why it "would be needed".

I thought this was a different issue. Sorry for the confusion!

Some languages in the ML family support struct assignment with a field update: for example, Rust has struct update syntax using the .. token, and OCaml has functional update notation using the with keyword.

Something more like that seems like it would address not only this use-case, but perhaps also some related ones (such as #33957). For Go, I would be inclined to use the ... token, by analogy to its use for slices:

    res := Foo{
        Name: "bar",
    }
    res = Foo{
        res...,
        ID: "1234",
        Name: "Foo",    
    }

or perhaps

    res := Foo{
        Name: "bar",
    }
    res = res...{
        ID: "1234",
        Name: "Foo",    
    }

The second possibility above leads to a natural variant of the = operator, by analogy to the existing +=, >>=, &^=, [鈥 variants:

    x.SomeDescriptiveFieldName ...= {
        ID: "1234",
        Name: "Foo",    
    }

could be a shorthand notation for

    x.SomeDescriptiveFieldName = x.SomeDescriptiveFieldName...{
        ID: "1234",
        Name: "Foo",    
    }

Exactly !

And the functional update object could be a struct, so that you could merge struct with same syntax.

patch := struct{
  Name string
}{
  Name: "foo"
}

x.SomeDescriptiveFieldName ...= patch

It's like using mergo but integrated in language.

@Zenithar, I don't think the RHS could be allowed to be a variable. That would be too ambiguous.

If I write:

patch := struct{
    ID string
    Name string
}{
    ID: "foo",
}
x.SomeDescriptiveFieldName ...= patch

should that set x.SomeDescriptiveFieldName.Name to the empty string, or leave it alone? I could plausibly argue for either, which suggests that either choice would cause confusion for somebody.

For clarity, it seems to me that the thing being mixed in must always be a literal.

No change in consensus on this specific proposal.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rsc picture rsc  路  3Comments

OneOfOne picture OneOfOne  路  3Comments

bradfitz picture bradfitz  路  3Comments

enoodle picture enoodle  路  3Comments

michaelsafyan picture michaelsafyan  路  3Comments