Thread overview
UFCS limit
Jun 16
Antonio
Jun 17
Tejas
Jun 17
bauss
Jun 17
Antonio
Jun 17
Antonio
June 16
auto doSomething(string text)
{
  return (string text2)
  {
    import std.stdio;
    writeln(text,",",text2);
  };
}

void main()
{
  doSomething("Hello")("X");
  "X".doSomething("Hello")();
}

Compiler error:

...
onlineapp.d(13):        expected 1 argument(s), not 2

I tried with some syntax change:

void main()
{
  doSomething("Hello")("X");
  (doSomething("Hello"))("X"); // it works
  "X".(doSomething("Hello"))(); // fails!!!
}

```onlineapp.d(14): Error: identifier or new expected following `.`, not `(````

Is it there any way to apply UFCS on the returned method in the same expression?

June 17

On Thursday, 16 June 2022 at 23:59:06 UTC, Antonio wrote:

>

Is it there any way to apply UFCS on the returned method in the same expression?

Nope. The way UFCS works is that allows you to call free functions using member-function syntax, and member-function syntax is always object.memberName, so UFCS only works for functions that have a name, not anonymous functions.

June 17

On Friday, 17 June 2022 at 01:04:28 UTC, Paul Backus wrote:

>

Nope. The way UFCS works is that allows you to call free functions using member-function syntax, and member-function syntax is always object.memberName, so UFCS only works for functions that have a name, not anonymous functions.

Would it be worthwhile to extend the scope of UFCS to accomodate this use case as well though??

June 17

On Friday, 17 June 2022 at 05:17:20 UTC, Tejas wrote:

>

On Friday, 17 June 2022 at 01:04:28 UTC, Paul Backus wrote:

>

Nope. The way UFCS works is that allows you to call free functions using member-function syntax, and member-function syntax is always object.memberName, so UFCS only works for functions that have a name, not anonymous functions.

Would it be worthwhile to extend the scope of UFCS to accomodate this use case as well though??

Probably not.

June 17

On Friday, 17 June 2022 at 05:17:20 UTC, Tejas wrote:

>

On Friday, 17 June 2022 at 01:04:28 UTC, Paul Backus wrote:

>

Nope. The way UFCS works is that allows you to call free functions using member-function syntax, and member-function syntax is always object.memberName, so UFCS only works for functions that have a name, not anonymous functions.

Would it be worthwhile to extend the scope of UFCS to accomodate this use case as well though??

I think it would lead to a lot of confusing and ambiguity.

June 17

On Friday, 17 June 2022 at 01:04:28 UTC, Paul Backus wrote:

>

On Thursday, 16 June 2022 at 23:59:06 UTC, Antonio wrote:

>

Is it there any way to apply UFCS on the returned method in the same expression?

Nope. The way UFCS works is that allows you to call free functions using member-function syntax, and member-function syntax is always object.memberName, so UFCS only works for functions that have a name, not anonymous functions.

Lets tray with a name :-)

auto doSomething(string text)
{
  return (string text2)
  {
    import std.stdio;
    writeln(text,",",text2);
  };
}

void main()
{
  auto doHello = doSomething("Hello");
  doHello("X");
  "X".doHello();
}

Error: onlineapp.d(16): Error: no property doHello for type string

It's true... the favomous "Rationale: Local function symbols are not considered by UFCS to avoid unexpected name conflicts." (I consider it absurd... but I'n no-one)

Well lets try another possibility taking in account the power of CTFE

auto doSomething(string text)
{
  return (string text2)
  {
    import std.stdio;
    writeln(text,",",text2);
  };
}

auto doHello = doSomething("Hello");

void main()
{
  doHello("X");
  "X".doHello();
}

Error: onlineapp.d(3): Error: closures are not yet supported in CTFE

:-/

UFCS vs Functional curring... nice battle :-)

June 17

On Friday, 17 June 2022 at 12:26:05 UTC, Antonio wrote:

>

UFCS vs Functional curring... nice battle :-)

UFCS & CFTE vs Functional currying... nice battle :-)