[css-mixins] Should `result` be mandatory in `@function`?

[cdoublev]

Based on the original proposal...

[...] a function would need to define one or more resulting values to return [...]

... and the procedure evaluate a custom function

3. Let result be the resolved local value of the result descriptor [...]

... and common sense (@function would be useless if it returns nothing, presumably equivalent to returning a guaranteed invalid value), I would say that result should be required for @function to be valid, which is currently not explicitly defined in 2.1. The @function Rule or 2.2. The result Descriptor.

[tabatkins]

While a function without a result is indeed useless, you can have a function with a result that still doesn't get executed, by having it in a false MQ or something. So we'll need to define what happens when no result ends up being encountered anyway (just makes the value IACVT, I'd think), and then I don't see a great reason to have special logic for when you just omit result entirely.

[andruud]

you can have a function with a result that still doesn't get executed, by having it in a false MQ or something

It's still possible to require that a result must appear directly beneath @function (perhaps in addition to results inside MQs, etc), causing some result to always be encountered.

However, other languages have stuff like std::optional, Java Optional, etc, where returning nothing means the caller has to decide what to do. The same is possible in CSS if we return guaranteed-invalid for result-less functions:

--x: --maybe-no-result();
width: var(--x, 42px);

I think I prefer to leave results optional for this reason, even if it currently requires noisy indirection via a custom prop.

[mirisuzanne]

I like the proposal here - suggest we take it to the group for a resolution. (though that may not be essential pre-FPWD?)

[css-meeting-bot]

The CSS Working Group just discussed [css-mixins] Should `result` be mandatory in `@function`?, and agreed to the following:

• RESOLVED: result is optional in @function

The full IRC log of that discussion

<kbabbitt> TabAtkins: the question raised here is should the result descriptor be mandatory in @function rule
<kbabbitt> ... result describes what function returns
<kbabbitt> ... is it strictly required to have it, or can it be omitted with reasonable default behavior
<kbabbitt> ... thread is leaning towards it should be optional
<kbabbitt> ...IACVT if there isn't one
<kbabbitt> ... matches up with other languages concepts of optional
<kbabbitt> ... at the moment you have to indirect through a custom property to use this value instead if IACVT
<kbabbitt> ... we have other proposals to make that easier
<kbabbitt> ... unless there's a great reason to require it, we think it's fine to let it be omitted
<kbabbitt> ... and have it be IACVG when that hits
<kizu> +1 to be optional
<kbabbitt> s/IACVG/IACVT/
<lea> q?
<miriam> +1
<lea> q+
<kbabbitt> astearns: other opinions/questions?
<astearns> ack lea
<kbabbitt> lea: if result is mandatory does that mean rule is tropped at parse iyme if it's missing?
<kbabbitt> TabAtkins: yes
<kbabbitt> lea: might be use cases to add later? could just have dummy one
<kbabbitt> Proposed: result is optional in @function
<kbabbitt> RESOLVED: result is optional in @function