auto bug(alias f)()
{
    return cast(typeof(f))&f;
}

void fun() {}

void main()
{
	bug!fun(); //Error: functions cannot return a function
}

On Thursday, November 17, 2016 01:27:45 Meta via Digitalmars-d wrote:
> auto bug(alias f)()
> {
>      return cast(typeof(f))&f;
> }
>
> void fun() {}
>
> void main()
> {
>   bug!fun(); //Error: functions cannot return a function
> }

Well, you _can't_ return a function. You could return a function pointer or a delegate, but not a function. What would it even mean to return a function?

Why don't you just return &f? I don't understand why you're doing the cast. &f should give you a pointer to f, so you have a function pointer that you can then call later (though you'd need to assign the result of bug!fun() to a variable, since it does nothing otherwise).

-  Jonathan M Davis

On Thursday, 17 November 2016 at 01:27:45 UTC, Meta wrote:
> auto bug(alias f)()
> {
>     return cast(typeof(f))&f;
> }
>
> void fun() {}
>
> void main()
> {
> 	bug!fun(); //Error: functions cannot return a function
> }

Got a bit ahead of myself. Found this in DMD 2.072.0.

On Thursday, 17 November 2016 at 01:48:51 UTC, Jonathan M Davis wrote:
> Well, you _can't_ return a function. You could return a function pointer or a delegate, but not a function. What would it even mean to return a function?

Well, it works. This compiles:

auto bug(alias f)()
{
    return f;
}

void fun() {}

void main()
{
	bug!fun(); //Error: functions cannot return a function
}

So why can't I return cast(typeof(f))&f? Furthermore, it gives me the exact same error when I change it to `return *&f`.

On Thursday, 17 November 2016 at 02:14:43 UTC, Meta wrote:
> On Thursday, 17 November 2016 at 01:48:51 UTC, Jonathan M Davis wrote:
>> Well, you _can't_ return a function. You could return a function pointer or a delegate, but not a function. What would it even mean to return a function?
>
> Well, it works. This compiles:
>
> auto bug(alias f)()
> {
>     return f;
> }
>
> void fun() {}
>
> void main()
> {
> 	bug!fun(); //Fine
> }


Should be:

void main()
{
	bug!fun(); //Fine
}

On Thursday, 17 November 2016 at 02:15:49 UTC, Meta wrote:
> On Thursday, 17 November 2016 at 02:14:43 UTC, Meta wrote:
>> On Thursday, 17 November 2016 at 01:48:51 UTC, Jonathan M Davis wrote:
>>> Well, you _can't_ return a function. You could return a function pointer or a delegate, but not a function. What would it even mean to return a function?
>>
>> Well, it works. This compiles:
>>
>> auto bug(alias f)()
>> {
>>     return f;
>> }
>>
>> void fun() {}
>>
>> void main()
>> {
>> 	bug!fun(); //Fine
>> }
>
>
> Should be:
>
> void main()
> {
> 	bug!fun(); //Fine
> }


I think you are doing a parenthesis-less call.

On Thursday, 17 November 2016 at 02:47:50 UTC, Stefan Koch wrote:
> I think you are doing a parenthesis-less call.

I swear optional parens is going to drive me insane. Why @property wasn't just fixed instead of the current horribly broken and unintuitive situation, I'll never know.

On Thursday, November 17, 2016 02:53:50 Meta via Digitalmars-d wrote:
> On Thursday, 17 November 2016 at 02:47:50 UTC, Stefan Koch wrote:
> > I think you are doing a parenthesis-less call.
>
> I swear optional parens is going to drive me insane. Why @property wasn't just fixed instead of the current horribly broken and unintuitive situation, I'll never know.

The number one reason? Because folks hated the extra parens with UFCS. e.g. with optional parens, you get stuff like

auto r = range.map!foo.filter!(a => a < 5);

whereas without them you have to do

auto r = range.map!foo().filter!(a => a < 5)();

With UFCS and ranges, you end up with a lot of situations where you use parens for the template argument, and a lot of folks thought that then having to put the empty parens on the end was just ugly. If we didn't have UFCS, then optional parens used with non-property functions would be a lot less appealing. But once UFCS was added, any chance of having strong property enforcement for @property pretty much died. As it stands, we really should fix @property for callables so that you can use @property to have a property function which returns a callable and is called without the extra parens, or we should arguably just get rid of @property.

Regardless, optional parens are one of those features that seems really nice in some situations and gets really annoying in others, and you hit one of those spots where it's annoying.

- Jonathan M Davis

On Thursday, 17 November 2016 at 03:10:33 UTC, Jonathan M Davis wrote:
> Regardless, optional parens are one of those features that seems really nice in some situations and gets really annoying in others, and you hit one of those spots where it's annoying.

I would be feasible to only recognize parenthesis-less calls as calls in UFCS situations.
The increase in sema-complexity is not high.