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: compact syntax for multiple property assignation on a same object. #35528

Closed
Zenithar opened this issue Nov 12, 2019 · 14 comments
Closed
Milestone

Comments

@Zenithar
Copy link

Zenithar commented Nov 12, 2019

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.

@gopherbot gopherbot added this to the Proposal milestone Nov 12, 2019
@ianlancetaylor ianlancetaylor added v2 A language change or incompatible library change LanguageChange labels Nov 12, 2019
@ianlancetaylor
Copy link
Contributor

Today you can already write

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

@Zenithar
Copy link
Author

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.

@Zenithar
Copy link
Author

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"

@Zenithar
Copy link
Author

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

@randall77
Copy link
Contributor

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.

@ianlancetaylor
Copy link
Contributor

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.

@jimmyfrasche

This comment has been minimized.

@ianlancetaylor

This comment has been minimized.

@jimmyfrasche

This comment has been minimized.

@bcmills
Copy link
Contributor

bcmills commented Dec 4, 2019

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",	
	}

@bcmills
Copy link
Contributor

bcmills commented Dec 4, 2019

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",	
	}

@Zenithar
Copy link
Author

Zenithar commented Dec 6, 2019

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.

@bcmills
Copy link
Contributor

bcmills commented Jan 7, 2020

@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.

@bradfitz bradfitz added the dotdotdot ... label Jan 7, 2020
@ianlancetaylor
Copy link
Contributor

No change in consensus on this specific proposal.

@golang golang locked and limited conversation to collaborators Jan 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants