recently, I visited the glossary and saw that functor exist in D...I know that functor exist C++ as a way to easily allow higher order function, but since D already has function and delegates, is there a point to functor ?

On 6/22/18 10:06 AM, Flaze07 wrote:
> recently, I visited the glossary and saw that functor exist in D...I know that functor exist C++ as a way to easily allow higher order function, but since D already has function and delegates, is there a point to functor ?

D covers a lot of programming paradigms. It has Java-like classes and interfaces, and C++-like functors, along with pure functions, (good) templates, immutable data, concurrency, etc.

It's meant to make it easy to transition to D from the language you are used to.

There's no specific reason to use functors, but if you want to, you can, as most of std.algorithm supports them (see https://dlang.org/phobos/std_traits.html#isCallable).

-Steve

On Friday, 22 June 2018 at 14:06:06 UTC, Flaze07 wrote:
> recently, I visited the glossary and saw that functor exist in D...I know that functor exist C++ as a way to easily allow higher order function, but since D already has function and delegates, is there a point to functor ?

It there for Extern(C++).

On 06/22/2018 08:17 AM, Steven Schveighoffer wrote:

> reason to use functors

I wonder whether they are more efficient because a functor would carry just the state that it needs. Also, there is no GC memory allocation unless the programmer wants to.

I wonder how much state is allocated for a delegate?

Ali

On Friday, June 22, 2018 14:06:06 Flaze07 via Digitalmars-d-learn wrote:
> recently, I visited the glossary and saw that functor exist in D...I know that functor exist C++ as a way to easily allow higher order function, but since D already has function and delegates, is there a point to functor ?

D is a multi-paradigm language that has operator overloading, so it pretty much naturally ends up with functors whether it was specifically planned for or not, though I'm not sure that they get used all that much. I think that some folks do use them instead of delegates in some situations, because delegates allocate closures to hold their state (copying the associated stack onto GC-allocated memory). So, if you have code that you want or need to be @nogc, delegates aren't going to work, whereas functors can. The biggest reason that a lot of Phobos has trouble being used in @nogc code is because of closures being allocated for lambdas (since lambdas are frequently delegates), and if someone goes to the extra effort of using functors instead of lambdas, they can avoid those allocations. But I think that most folks don't worry about it and just use lambdas. It's the folks that either actually need @nogc or are just paranoid about the GC that most typically try to avoid such allocations - though I'm sure that we'd all love it if the compiler could be a bit smarter about not allocating closures when they're not actually needed (it's pretty conservative about it, because if it ever doesn't allocate a closure when one was needed, then you have an @safety bug).

- Jonathan M Davis

On 6/22/18 2:25 PM, Ali Çehreli wrote:
> On 06/22/2018 08:17 AM, Steven Schveighoffer wrote:
> 
>  > reason to use functors
> 
> I wonder whether they are more efficient because a functor would carry just the state that it needs. Also, there is no GC memory allocation unless the programmer wants to.
> 
> I wonder how much state is allocated for a delegate?

If it's not a closure, then none. It just uses the stack frame.

Most of the time you would just use an alias instead of a functor or a delegate.

-Steve

On Friday, 22 June 2018 at 20:20:56 UTC, Steven Schveighoffer wrote:
> On 6/22/18 2:25 PM, Ali Çehreli wrote:
>> On 06/22/2018 08:17 AM, Steven Schveighoffer wrote:
>> 
>>  > reason to use functors
>> 
>> I wonder whether they are more efficient because a functor would carry just the state that it needs. Also, there is no GC memory allocation unless the programmer wants to.
>> 
>> I wonder how much state is allocated for a delegate?
>
> If it's not a closure, then none. It just uses the stack frame.
>
> Most of the time you would just use an alias instead of a functor or a delegate.
>
> -Steve

I see, thank you