-
Notifications
You must be signed in to change notification settings - Fork 303
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
Question mark operator for unwrapping optional values #551
Comments
An alternative to select_first for "unoptionaling" (there's probably a better word for this...) variables sounds like a good idea to me. It always seemed a bit unintuitive that you had to use
In command sections it is pretty common to add an optional to a String. As this will result in eg. currently this is possible: Int? optional_value
# [...]
~{"--optional-option " + optional_value} The alternative (which would have to be used if the above gets deprecated) is a lot more verbose: # current syntax
~{if defined(optional_value) then "--optional-option " + select_first([optional_value]) else ""}
# proposed syntax
~{if defined(optional_value) then "--optional-option " + optional_value? else ""} |
Your strength is your weakness and your weakness is your strength. On one hand The question mark is subtle, but I wonder if it isn't too subtle. How about a function called
Looking at the code example, that actually looks quite nice! |
@DavyCats I borrowed the "unwrap" terminology from Rust, which has an When I talk about special casing, I'm referring to the two exceptions mentioned here: https://github.com/openwdl/wdl/blob/main/versions/1.1/SPEC.md#coercion-of-optional-types. The behavior of "catching" exceptions in placeholders and converting them to @rhpvorderman I'm somewhat ambivalent with a slight preference for the |
But declaration and unwrapping are different. So why use the same operator?
I think both |
I like the use of So, I'd vote for |
This is purely syntactic sugar for
select_first([x])
wherex
is a value that may beNone
.If we add this operator then we can get away from special-casing optional behavior within string interpolations. I.e.
"~{x + y}"
would no longer be allowed (i.e. deprecated in 1.2 and disallowed in 2.0) and instead you'd have to write"~{x? + y?}"
, just as you would in an expression outside of an interpolation.The text was updated successfully, but these errors were encountered: