On Fri, 21 Jun 2024, at 15:21, Pierre wrote:
> I don't see the use of a syntax such as `$foo as ?int` since all
> existing types of coercion are already possible via the cast syntax
> (please correct me if I'm wrong).
The current cast syntax (and its functional version, intval() etc) only
performs a single "type of coercion": make a best effort to guess the value,
silently use a fallback value, never fail. (int)'123hello' is 123,
(int)'complete nonsense' is 0. It also doesn't support nullable types, union
types, etc, and it's not clear what it should do if it did.
There is currently no syntax or function to explicitly perform the coercion
that mode 0 scalar parameters perform, where '123hello' and 'complete nonsense'
both produce a TypeError. Nor is there any syntax or function that can answer
the question "would this value be accepted as {type} in mode 0?"
> In almost every case you would need coercion you also need validation,
> and validation is not something that's possible with a neat syntax,
I don't see why validation can't be concise, for extremely common cases, such
as "Is this string obviously an integer?"
> at least not this one
I'm not sure what you mean by that; I consider the syntax to use very much an
open question, and if I get time to write up a proposal, would like to discuss
the pros and cons of various options.
That could be as simple as a built-in function, but might benefit from
first-class syntax so that it can be used with any type without passing it as a
string.
Regards,
--
Rowan Tommins
[IMSoP]
