You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today we have an ability to configure some of the members as positional arguments to the starting function that creates the builder or to the finishing function that consumes the builder, however, we don't have the ability to configure members as positional arguments to the setters themselves.
So for example if you want to have a setter that accepts two positional parameters (e.g. x and y coordinates) we can't do that. So in order to be able to do that I propose the following syntax.
All members with builder(name = ...) with the same name are grouped under a single setter with that name. Also all members with that name must be located adjacently in the declaration.
Unresolved questions
Now the question arises what to do with optional members that would like to have such syntax? An obvious and easy answer would be just not to support them at least initially.
Also what if we already have a member with the identifier conflicting with the name attribute placed on some other members? Maybe we should just disallow it unless it has its own name attribute.
Documentation and other item level attributes for the setter
Now that we have a single setter for multiple members how can we generate documentation for it. Or rather most importantly how can the user write documentation for this setter. There should be some single place to document this setter.
Maybe the docs on the first member in the group will be the docs on the setter. But then it would break the consistency with the start_fn and finish_fn annotations on members. Because in their case the documentation isn't inherited anywhere. But we can change that... For example, we can say that the documentation on all members is just concatenated together and inserted into the final documentation at a specified place but how to specify it?
Destructuring syntax
As a shorthand notation for a group of positional parameters passed as a single unit through a single function including for start FN and finish fn parameters we could use destructuring.
This syntax can have two forms one is for functions where it's possible to do the destructuring natively via the pattern syntax.
(x, y):(f32, f32)
Such a notation will be specially handled by the builder macro. It will generate a single setter for this pair of x and y.
But then the user still needs to specify the name of the setter...
This also doesn't work in struct syntax. There we need to have an ability to group members by annotating them with attributes. For example the following syntax that resembles destructuring can be applied to a member of tuple type:
#[builder(name = (x, y))]point:(f32, f32)
This however makes the name attribute a bit overloaded. Maybe there should be a separate attribute for this specific purpose. I'm not sure yet but I think this is a good first step into the final design.
A note for the community from the maintainers
Please vote on this issue by adding a 👍 reaction to help the maintainers with prioritizing it. You may add a comment describing your real use case related to this issue for us to better understand the problem domain.
The text was updated successfully, but these errors were encountered:
Veetaha
changed the title
Group several members as positional arguments to a single setter
Support grouping several members as positional arguments to a single setter
Nov 10, 2024
Today we have an ability to configure some of the members as positional arguments to the starting function that creates the builder or to the finishing function that consumes the builder, however, we don't have the ability to configure members as positional arguments to the setters themselves.
So for example if you want to have a setter that accepts two positional parameters (e.g. x and y coordinates) we can't do that. So in order to be able to do that I propose the following syntax.
All members with
builder(name = ...)
with the same name are grouped under a single setter with that name. Also all members with that name must be located adjacently in the declaration.Unresolved questions
Now the question arises what to do with optional members that would like to have such syntax? An obvious and easy answer would be just not to support them at least initially.
Also what if we already have a member with the identifier conflicting with the name attribute placed on some other members? Maybe we should just disallow it unless it has its own name attribute.
Documentation and other item level attributes for the setter
Now that we have a single setter for multiple members how can we generate documentation for it. Or rather most importantly how can the user write documentation for this setter. There should be some single place to document this setter.
Maybe the docs on the first member in the group will be the docs on the setter. But then it would break the consistency with the start_fn and finish_fn annotations on members. Because in their case the documentation isn't inherited anywhere. But we can change that... For example, we can say that the documentation on all members is just concatenated together and inserted into the final documentation at a specified place but how to specify it?
Destructuring syntax
As a shorthand notation for a group of positional parameters passed as a single unit through a single function including for start FN and finish fn parameters we could use destructuring.
This syntax can have two forms one is for functions where it's possible to do the destructuring natively via the pattern syntax.
Such a notation will be specially handled by the builder macro. It will generate a single setter for this pair of x and y.
But then the user still needs to specify the name of the setter...
This also doesn't work in struct syntax. There we need to have an ability to group members by annotating them with attributes. For example the following syntax that resembles destructuring can be applied to a member of tuple type:
This however makes the name attribute a bit overloaded. Maybe there should be a separate attribute for this specific purpose. I'm not sure yet but I think this is a good first step into the final design.
A note for the community from the maintainers
Please vote on this issue by adding a 👍 reaction to help the maintainers with prioritizing it. You may add a comment describing your real use case related to this issue for us to better understand the problem domain.
The text was updated successfully, but these errors were encountered: