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

Primary constructors with curly brackets for user-named fields #3198

Closed
Cat-sushi opened this issue Jul 6, 2023 · 5 comments
Closed

Primary constructors with curly brackets for user-named fields #3198

Cat-sushi opened this issue Jul 6, 2023 · 5 comments
Labels
feature Proposed language feature that solves one or more problems

Comments

@Cat-sushi
Copy link

Cat-sushi commented Jul 6, 2023

For consistency with records, like

typedef R = (int, {int a, int b});
R r = /* R */(1, a:2, b:3);
main(){
  print(r.$1);
  print(r.a);
  print(r.b);
}

, I think that primary constructors should have syntax with curly brackets for user-named fields, like

data class D(int, {int a, int b});
D d = D(1, a:2, b:3);
main(){
  print(d.$1);
  print(d.a);
  print(d.b);
}

.

My understanding is that data classes are records with class names, both of them share characteristics of simple, immutable, unboxing optimization friendly, without persistent identity, and with structural equality, in other words value types, then syntactic consistency is important.

@Cat-sushi Cat-sushi added the feature Proposed language feature that solves one or more problems label Jul 6, 2023
@lrhn
Copy link
Member

lrhn commented Jul 6, 2023

A primary constructor is, as discussed so far, very much a parameter list with extra keywords allowed (because each parameter is also going to declare a field, and the fields may need more keywords).

What you describe is how named parameters are already written, so it's pretty much a given that the syntax for primary constructors will use that for named parameters.
(Meaning that wrt. curly braces, you can probably closed this issue as "fixed", because that's how it's going to be, if it is at all.)

I'm less enthusiastic about omitting the name for a positional field, because $1 is not a good name for something that you can easily give a better name. And you can still name it $1 if you really mean that.

Records got the $1 names because they are structural, so there is no single declaration which can name the first positional element, and because we hope you'll be using patterns to destructure instead of .$1 most of the time.

And there is no way that primary constructors will not allow class D(int $1, {int a, int b}); as syntax.
(But if it's a class, you probably want to add final too. For a data class where fields must be final, if that becomes a thing, the final can probably be omitted.)

@Cat-sushi
Copy link
Author

I'm relieved.
Is there a proposal which specify this syntax as "fixed" one?

@Cat-sushi
Copy link
Author

this one?
language/working/extension_structs/overview.md at main · dart-lang/language

Is "Alternative:" user selectable option, or language designers option?

@lrhn
Copy link
Member

lrhn commented Jul 6, 2023

I believe the most current proposal for primary constructors is the open PR #3023

@Cat-sushi
Copy link
Author

Thank you.
I'm closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Proposed language feature that solves one or more problems
Projects
None yet
Development

No branches or pull requests

2 participants