[webkit-dev] Should we ever use std::function instead of WTF::Function?

[Filip Pizlo]

We should have a better story here.  Right now the story is too complicated.  We have:

- ScopedLambda or ScopedLambdaRef if you have a stack-allocated function that outlives its user
- SharedTask if you have a heap-allocated function that you want to share and ref-count
- WTF::Function if you have a heap-allocated function that you want to transfer ownership (move yes, copy no)
- std::function if you have a heap-alloated function that you want to pass by copy

Only std::function and WTF::Function do the magic that lets you say:

std::function f = <lambda>

Also, std::function has the benefit that it does copying.  None of the others do that.

ScopedLambda serves a specific purpose: it avoids allocation.  Probably we want to keep that one even if we merge the others.

IMO SharedTask has the nicest semantics.  I don’t ever want the activation of the function to be copied.  In my experience I always want sharing if more than one reference to the function exists.  I think that what we really want in most places is a WTF::Function that has sharing semantics like SharedTask.  That would let us get rid of std::function and SharedTask.

In the current status quo, it’s not always correct to convert std::function to the others because:

- Unlike ScopedLambda and SharedTask, std::function has the magic constructor that allows you to just assign a lambda to it.
- Unlike ScopedLambda, std::function is safe if the use is not scoped.
- Unlike WTF::Function, std::function can be copied.

-Filip


> On Jun 13, 2017, at 9:24 AM, Darin Adler <darin at apple.com> wrote:
> 
> I’ve noticed many patches switching us from std::function to WTF::Function recently, to fix problems with copying and thread safety.
> 
> Does std::function have any advantages over WTF::Function? Should we ever prefer std::function, or should we use WTF::Function everywhere in WebKit where we would otherwise use std::function?
> 
> — Darin
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev