Rename `$derived.call` to `$derived.lazy`

[Rich-Harris]

Describe the problem

In #10240 we added $derived.call(fn) alongside $derived(expression), and somehow overlooked the fact that Function.prototype.call is a thing.

Strictly speaking this is fine — these are runes, not functions, and we can do what the hell we want. But realistically this is going to be a source of confusion at best and annoyance at worst for many people.

Describe the proposed solution

Programmers often talk about 'lazy evaluation', which basically means providing a function to compute some value rather than the value itself.

Even though the under-the-hood mechanism of $derived is that it's always lazy, meaning that this...

let value = $derived(expression);

...is syntactic sugar for this...

let value = $derived.call(() => expression);

...I think the conceptual framing is the right one. I therefore propose $derived.lazy:

let a = $derived(expression); // evaluated eagerly
let b = $derived.lazy(() => expression); // evaluated lazily

We'll also need to add an error message for anyone who is already using $derived.call, of course.

Importance

would make my life easier

[trueadm]

To me this API implies that the $default way isn't lazy somehow. I think I prefer $derived.thunk the function can't take arguments.

https://en.wikipedia.org/wiki/Thunk

[Rich-Harris]

'Thunk' is a nonsense programming word. It means nothing to most people. If you google it, this is what you get:

Svelte needs to have broader appeal than people who learned esoteric terminology while studying Computer Science

[dummdidumm]

$derived.fn 🙃

[MotionlessTrain]

This is actually more of a problem than it may look (other that being confusing):
It also messes with the Typescript definition of $derived: As $derived is typed as a function, $derived.call is automatically typed as Function.prototype.call, so $derived.call is only useable when you are not using typescript, or disable that line for the typescript compiler

Maybe $derived.invoke could work?

[Rich-Harris]

Other ideas that have come up — $derived.using(fn) and $derived.from(fn).

The main reason we didn't go with $derived.from is that we might want to use that in future for other things:

$derived.from(observable);
$derived.from(store);
$derived.from(async_iterable);

But as soon as you have one $derived.from usage in your codebase, the code for all the things it supports must be included (i.e. not treeshaken). Without a clear sense of what values we'd eventually support, and how much code they would involve, the cautious thing to do would be to avoid .from.

Another naming consideration is how we talk about these things in the abstract. One thing I particularly like about .lazy is that it allows us to talk about a 'lazy derived' (or 'lazily derived state' to be pedantic); none of the other options I've seen have that characteristic.

[lucaesposto]

1. Does $derived.lazy executes a Lazy Evaluation ?
2. Does $derived not behaves this way, instead?

If one of the answers is no, i don't think $derived.lazy can be the right choice.

[brunnerh]

I do not like this name; it cannot be lazy because the function has to be evaluated immediately to determine the dependencies. As pointed out by Dominic, it evaluates on access.

Still, the name is odd if this is just different syntax and everything is lazy by default.

[navorite]

I honestly think the original name — $derived.fn is the best one. It does exactly what it is. I don't see using full names here as a problem as it wouldn't add any value.

On the other hand, I'd rather it be $derived.call than $dervied.lazy because this gives a false impression about $dervied and would add more confusion than the current one.

[trueadm]

I do not like this name; it cannot be lazy because the function has to be evaluated immediately to determine the dependencies.

The opposite is true actually. We don't evaluate them immediately ever, and only lazily invoke them when needed. We don't need to know about their dependencies until an effect or another derived needs to know about them.

[Rich-Harris]

Things I don't love about $derived.fn:

• it's an abbreviation (and not even an acronym at that) — we generally try to avoid this in Svelte. Abbreviations aren't always obvious to people
• it's not even a universal abbreviation for function. Many people use func, for example. Some people use fun
• it's often necessary to describe interfaces in the abstract, and in this case that means $derived.fn(fn). That makes me shudder

[lucaesposto]

Things I don't love about $derived.fn:

• it's an abbreviation (and not even an acronym at that) — we generally try to avoid this in Svelte. Abbreviations aren't always obvious to people
• it's not even a universal abbreviation for function. Many people use func, for example. Some people use fun
• it's often necessary to describe interfaces in the abstract, and in this case that means $derived.fn(fn). That makes me shudder

I strongly agree.
Can we properly say that the function we provide to $derived.something is a callback?

In that case, two options come to my mind:

• $derived.callback
• $derived.fromCallback

[gterras]

let a = $derived(expression); // evaluated eagerly
let b = $derived.lazy(() => expression); // evaluated lazily

I don't understand lazy at all in this context, if I see this in someone else's code it heavily implies that something different will happen under the hood and that I should go and check the docs to understand what. There is no way to intuitively tell yourself "ho lazy just means I can pass a function" it makes no sense.

I suppose it's been discussed but couldn't find it in the other thread, what's the technical limitation to just have

let a = $derived(expression); 
let b = $derived(() => expression);