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

Should VariantExpression allow expressions as keys? #188

Closed
stasm opened this issue Oct 19, 2018 · 2 comments
Closed

Should VariantExpression allow expressions as keys? #188

stasm opened this issue Oct 19, 2018 · 2 comments
Labels
FUTURE Ideas and requests to consider after Fluent 1.0 syntax

Comments

@stasm
Copy link
Contributor

stasm commented Oct 19, 2018

Given a term defined as follows:

-thing = {
    *[one] Thing
    [other] Things
}

Should we allow this?

own = You have { $count ->
    *[one] {-thing[$count]}
    [other] {-thing[$count]}
}

Right now we require the proper key to be specified in the VariantExpression, like so:

own = You have { $count ->
    *[one] {-thing[one]}
    [other] {-thing[other]}
}

Note that because we allow all valid variant keys, this is currently also legal:

own = You have { $count ->
    *[one] {-thing[1]}
    [other] {-thing[other]}
}
@stasm
Copy link
Contributor Author

stasm commented Oct 29, 2018

@Pike pointed out that we can't allow all inline expressions as keys because of the ambiguity of the -term[key] syntax. Right now key is the name of the requested variant, but if all expressions are allowed, it would parse as a MessageReference.

@stasm stasm added the FUTURE Ideas and requests to consider after Fluent 1.0 label Nov 2, 2018
@stasm
Copy link
Contributor Author

stasm commented Jan 31, 2019

With the removal of VariantLists and VariantExpressions in #204 and #214, this issue can be closed. However, the problem remains valid for named arguments in call expressions. I filed #230 to continue the discussion about them.

@stasm stasm closed this as completed Jan 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FUTURE Ideas and requests to consider after Fluent 1.0 syntax
Projects
None yet
Development

No branches or pull requests

1 participant