October 08, 2020
On 10/8/20 8:16 AM, Stefan Koch wrote:
> On Thursday, 8 October 2020 at 12:05:22 UTC, Andrei Alexandrescu wrote:
>>
>>
>> The following works:
>>
>> alias DerivedToFront(Args...) = dereify!({
>>     auto ids = reifyArray!Args;
>>     ids.sort;
>>     return ids;
>> }());
>>
>> https://gist.github.com/andralex/0d85df38be2d9ffbe89cf1fb51c44213
> 
> Only with the ID struct that defines the op-compare.
> Which is significantly more complicated that the custom sort predicate.
> And also more inflexible.

Less flexible during compilation, more flexible at runtime. It is quite satisfying that the same information in reified form (strings I think in that gist) is equally usable during compilation, at run-time, or in mixed scenarios (Variant).

I wonder what other information would be useful to persist through runtime aside from the trivial (size, alignment) and the more involved (enough information to decide conversions). For functions, I assume that would be the returned type and the parameter types along with all adornments (ref, out, all that stuff). For classes, interfaces, and structs, that would include all public methods - probably on demand by means of an @rtti attribute so as to not waste time and space.
October 08, 2020
On Thursday, 8 October 2020 at 13:12:22 UTC, Andrei Alexandrescu wrote:
> Less flexible during compilation, more flexible at runtime.

With my little lib that uses string lambdas for templates:

pragma(msg, reified!q{
        // string template lambda
        a.sizeof == 4
}.run!(types =>
        types.filter!(a => a) // normal std.algorithm!
).over!(string, int, float, Object));

October 08, 2020
On Thursday, 8 October 2020 at 13:19:48 UTC, Adam D. Ruppe wrote:
> On Thursday, 8 October 2020 at 13:12:22 UTC, Andrei Alexandrescu wrote:
>> Less flexible during compilation, more flexible at runtime.
>
> With my little lib that uses string lambdas for templates:
>
> pragma(msg, reified!q{
>         // string template lambda
>         a.sizeof == 4
> }.run!(types =>
>         types.filter!(a => a) // normal std.algorithm!
> ).over!(string, int, float, Object));

please post the source of your lib.
Benchmark is incoming.
October 08, 2020
On Thursday, 8 October 2020 at 10:16:10 UTC, Stefan Koch wrote:
> This is the correct type function way of doing it:
> enum type[] types = makeTypeArray(int, uint, long, ulong);
> enum type[] size4 = types.filter!((type a) => a.sizeof == 4);
> static assert(equal!((type a, type b) => a is b) (size4, makeTypeArray(int, uint)));
>
> Currently type[] fails is isInputRange though and therefore the phobos filter won't instantiate.
> I am debugging this.

This is plain awesome.

The fact that it reuses the filter algorithm is a sign that both filter and type functions are correctly designed.

Who could ever imagined that a template would be instantiated with a lambda that takes a type-value as an argument. WAT!? That is some high-order stuff, and perfectly readable.

Andrei's de/reify is awesome as well, it has the advantage of working with existing language constructs, but it isn't as simple.


October 08, 2020
On Thursday, 8 October 2020 at 13:27:50 UTC, Stefan Koch wrote:
> please post the source of your lib.

it is over here https://forum.dlang.org/post/zhaziudnbaoybmfdrzxn@forum.dlang.org

> Benchmark is incoming.

I don't expect it to win, this is more to demo existing language api style possibilities. This style lost to existing Phobos std.meta when I tried.
October 08, 2020
On Thursday, 8 October 2020 at 13:19:48 UTC, Adam D. Ruppe wrote:
>         a.sizeof == 4

Of course I probably should have written it:

pragma(msg, reified!q{
        a.sizeof // just get the size
}.run!(types =>
        types.filter!(a => a == 4) // and compare it down here
).over!(string, int, float, Object));

October 09, 2020
On Thursday, 1 October 2020 at 18:04:09 UTC, Bruce Carneal wrote:
> If that's where you're headed, if you want to destroy the compile-time/run-time separation, I'd be interested in hearing more.  I'm not a fan of embedding the compiler or exposing the type system for that matter, but it would be worth a listen, no doubt.


Doesn't C# expose the compiler as a library (Roslyn)? Might be worth looking into.
2 3 4 5 6 7 8 9 10 11 12
Next ›   Last »