June 17, 2020
On Wednesday, 17 June 2020 at 16:01:29 UTC, Paul Backus wrote:
> [snip]
>
> IMO this can be done more elegantly by separating out the code that looks up methods in the current module from the code that does the actual type erasure.
>
> A while ago, I collaborated briefly with Adam Kowalski from the Dlang discord server on some code to emulate C++-style argument-dependent lookup in D. Using that code, your example above would be written:
>
>     Geometry.create(r.extended).measure;
>     Geometry.create(c.extended).measure;
>
> Here's a gist with the code, along with a small example:
>
> https://gist.github.com/pbackus/0a70419eb8bece52f3a08edfe7b6019b
>
> If anyone thinks it's worthwhile, I can toss this up on Dub. Personally, I've never had much use for it in my own projects.

The syntax there looks nice (wouldn't hurt to make it even nicer!).

Your moduleOf (and associated functions) looks like it shares similar functionality as some of what is in vtableImpl in poly.d (particularly importMixin).
June 17, 2020
On Wednesday, 17 June 2020 at 16:01:29 UTC, Paul Backus wrote:
> A while ago, I collaborated briefly with Adam Kowalski from the Dlang discord server on some code to emulate C++-style argument-dependent lookup in D. Using that code, your example above would be written:
>
>     Geometry.create(r.extended).measure;
>     Geometry.create(c.extended).measure;
>
> Here's a gist with the code, along with a small example:
>
> https://gist.github.com/pbackus/0a70419eb8bece52f3a08edfe7b6019b
>
> If anyone thinks it's worthwhile, I can toss this up on Dub. Personally, I've never had much use for it in my own projects.

Yeah I can see a use for this. If have had to refactor things before because I was hitting this restriction.

June 18, 2020
On 6/17/20 7:19 AM, Atila Neves wrote:
> On Wednesday, 17 June 2020 at 10:43:35 UTC, Stanislav Blinov wrote:
>> On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
>>
>>> Tardy lets users have their cake and eat it too by not making them have to use classes for runtime polymorphism.
>>
>> I've got to ask though. Why "tardy"? Search engines be damned? :)
> 
> Late binding ;)

Love the name.
June 19, 2020
On Wednesday, 17 June 2020 at 16:01:29 UTC, Paul Backus wrote:
> On Tuesday, 16 June 2020 at 13:31:49 UTC, Atila Neves wrote:
>>
>> <snip>
>>
>> With a few changes, yes (added missing semicolons, changed IGeometry to Geometry in `measure`, passed the current module so tardy can find the UFCS functions, added `@safe pure` to the UFCS functions:
>>
> [...]
>>
>> void main() {
>>     auto r = Rect(3.0, 4.0);
>>     auto c = Circle(5.0);
>>
>>     Geometry.create!__MODULE__(r).measure;
>>     Geometry.create!__MODULE__(c).measure;
>> }
>
> IMO this can be done more elegantly by separating out the code that looks up methods in the current module from the code that does the actual type erasure.
>
> A while ago, I collaborated briefly with Adam Kowalski from the Dlang discord server on some code to emulate C++-style argument-dependent lookup in D. Using that code, your example above would be written:
>
>     Geometry.create(r.extended).measure;
>     Geometry.create(c.extended).measure;


Interesting.

The issue I see here is you might not be able to control which module has the extension methods. I guess you could alias them in the module you want to use but that seems clumsy.

In any case, this is trivial:

template extended(string mod = __MODULE__) {
    auto extended(A...)(auto ref A args) {
        return create!mod(args);
    }
}

1 2 3 4
Next ›   Last »