Re: bolts meta programming library version 1.0.0 - including the from idiom

2019-07-23 Thread Atila Neves via Digitalmars-d-announce

On Tuesday, 16 July 2019 at 20:18:30 UTC, John Colvin wrote:

On Tuesday, 16 July 2019 at 18:18:50 UTC, Atila Neves wrote:

On Tuesday, 16 July 2019 at 00:10:19 UTC, Aliak wrote:

On Monday, 15 July 2019 at 21:20:16 UTC, Atila Neves wrote:

On Monday, 15 July 2019 at 11:13:10 UTC, aliak wrote:

[...]


Nice! I'm working on something similar but with a different 
goal.


Thanks! How’s the thing similar and what’s the goal (if you 
don’t mind me asking)?


Similar: One-stop shop for reflection unifying the disparate 
APIs.
Goal: allow "regular" code for reflection purposes by (also) 
returning everything as strings.


Is this related to the talk Andrei gave at a recent dconf?


Yep!


Re: bolts meta programming library version 1.0.0 - including the from idiom

2019-07-17 Thread aliak via Digitalmars-d-announce

On Wednesday, 17 July 2019 at 16:29:34 UTC, victoroak wrote:

On Monday, 15 July 2019 at 11:13:10 UTC, aliak wrote:
I've been using a set of meta tools for a while now, so 
decided to release it as 1.0.0 with a few enhancements chucked 
on.


[...]


Looks nice. Though, I see it has some problems that stuck me 
before. The traits isFunctionOver and isUnaryOver can't handle 
lambdas that receive arguments by ref like:


struct S {}
static assert(isFunctionOver!((ref s) => s, S));

I wish ref was part of the type in D, so we could pass ref S as 
template parameters. I could pass as string but it's error 
prone and not really elegant.


Ooh! Thanks!

Fixed and released v1.0.1


Re: bolts meta programming library version 1.0.0 - including the from idiom

2019-07-17 Thread victoroak via Digitalmars-d-announce

On Monday, 15 July 2019 at 11:13:10 UTC, aliak wrote:
I've been using a set of meta tools for a while now, so decided 
to release it as 1.0.0 with a few enhancements chucked on.


[...]


Looks nice. Though, I see it has some problems that stuck me 
before. The traits isFunctionOver and isUnaryOver can't handle 
lambdas that receive arguments by ref like:


struct S {}
static assert(isFunctionOver!((ref s) => s, S));

I wish ref was part of the type in D, so we could pass ref S as 
template parameters. I could pass as string but it's error prone 
and not really elegant.


Re: bolts meta programming library version 1.0.0 - including the from idiom

2019-07-16 Thread John Colvin via Digitalmars-d-announce

On Tuesday, 16 July 2019 at 18:18:50 UTC, Atila Neves wrote:

On Tuesday, 16 July 2019 at 00:10:19 UTC, Aliak wrote:

On Monday, 15 July 2019 at 21:20:16 UTC, Atila Neves wrote:

On Monday, 15 July 2019 at 11:13:10 UTC, aliak wrote:
I've been using a set of meta tools for a while now, so 
decided to release it as 1.0.0 with a few enhancements 
chucked on.


[...]


Nice! I'm working on something similar but with a different 
goal.


Thanks! How’s the thing similar and what’s the goal (if you 
don’t mind me asking)?


Similar: One-stop shop for reflection unifying the disparate 
APIs.
Goal: allow "regular" code for reflection purposes by (also) 
returning everything as strings.


Is this related to the talk Andrei gave at a recent dconf?


Re: bolts meta programming library version 1.0.0 - including the from idiom

2019-07-16 Thread Atila Neves via Digitalmars-d-announce

On Tuesday, 16 July 2019 at 00:10:19 UTC, Aliak wrote:

On Monday, 15 July 2019 at 21:20:16 UTC, Atila Neves wrote:

On Monday, 15 July 2019 at 11:13:10 UTC, aliak wrote:
I've been using a set of meta tools for a while now, so 
decided to release it as 1.0.0 with a few enhancements 
chucked on.


[...]


Nice! I'm working on something similar but with a different 
goal.


Thanks! How’s the thing similar and what’s the goal (if you 
don’t mind me asking)?


Similar: One-stop shop for reflection unifying the disparate APIs.
Goal: allow "regular" code for reflection purposes by (also) 
returning everything as strings.


Re: bolts meta programming library version 1.0.0 - including the from idiom

2019-07-15 Thread Aliak via Digitalmars-d-announce

On Monday, 15 July 2019 at 21:20:16 UTC, Atila Neves wrote:

On Monday, 15 July 2019 at 11:13:10 UTC, aliak wrote:
I've been using a set of meta tools for a while now, so 
decided to release it as 1.0.0 with a few enhancements chucked 
on.


[...]


Nice! I'm working on something similar but with a different 
goal.


Thanks! How’s the thing similar and what’s the goal (if you don’t 
mind me asking)?


Re: bolts meta programming library version 1.0.0 - including the from idiom

2019-07-15 Thread Atila Neves via Digitalmars-d-announce

On Monday, 15 July 2019 at 11:13:10 UTC, aliak wrote:
I've been using a set of meta tools for a while now, so decided 
to release it as 1.0.0 with a few enhancements chucked on.


[...]


Nice! I'm working on something similar but with a different goal.


bolts meta programming library version 1.0.0 - including the from idiom

2019-07-15 Thread aliak via Digitalmars-d-announce
I've been using a set of meta tools for a while now, so decided 
to release it as 1.0.0 with a few enhancements chucked on.


Two of the highlights are the non-eponymous "member" and "iz" 
templates, which are shown below with some code. The library also 
includes the "from" template because I tend to use that 
everywhere.


Docs: https://aliak00.github.io/bolts/bolts.html
Github: https://github.com/aliak00/bolts
Package: https://code.dlang.org/packages/bolts

Current issues include:

1) that I'm not completely sure about the behaviour of the 
copy-constructor traits - I've decided to pretend post blots 
don't exist and marked the library as requiring dmd frontend 
2.086 and above.


2) It's an ongoing battle with D to normalize parameters because 
traits return tuples, or string, or tuples of strings, or alias 
tuples, etc. And some traits take symbols, while others take 
strings, etc. One of the goals is to make this library a little 
more consistent and try and keep it that way. I will break things 
to make things consistent (is my intention).


3) Naming - e.g. why are some things in std.meta capitalized 
(i.e. Filter) and others camel-cased with a static prefix - i.e. 
staticMap? What would be the consistent thing to do? I currently 
have a staticZip in there, should it just be Zip?


Some sample code:

unittest {
import bolts;

int i;
class C { void f0() {} int f1(int) { return 0; } }
static struct S { void f0() {} int f1(int) { return 0; } 
@property void set(int) {} }


pragma(msg, from.std.allSatisfy!(iz!int.of, 3, 4, int, i)); 
// true
pragma(msg, from.std.Filter!(isNullable, int*, C, S)); // 
(int*, C)


// Member functions
pragma(msg, memberFunctionsOf!S.asStrings); // tuple("f0", 
"f1")
pragma(msg, memberFunctionsOf!C.asAliases); // tuple(f0, f1, 
toString, toHash, opCmp, opEquals, factory)


// member template
pragma(msg, member!(S, "f0").exists); // true
pragma(msg, member!(S, "f0").protection); // public
pragma(msg, member!(S, "f0").isProperty); // false
pragma(msg, member!(S, "set").propertySemantics); // 
PropertySemantics.w


// iz template
static struct OldS {
this(this) {}
}
static struct NewS {
this(ref NewS s) {}
}
pragma(msg, iz!S.triviallyCopyConstructable); // yes
pragma(msg, iz!OldS.triviallyCopyConstructable); // no 
because post-blit
pragma(msg, iz!OldS.copyConstructable); // no because post 
blit


pragma(msg, iz!NewS.copyConstructable); // yes
pragma(msg, iz!NewS.nonTriviallyCopyConstructable); // yes

// meta fun with packs and zip
{
alias a = AliasPack!(1, 2, 3);
alias b = AliasPack!(4, 5, 6);
alias c = AliasPack!(7, 8, 9);

alias d = staticZip!(a, b, c);

static assert(d.length == 3);

static assert(d.Unpack[0].equals!(1, 4, 7));
static assert(d.Unpack[1].equals!(2, 5, 8));
static assert(d.Unpack[2].equals!(3, 6, 9));

static assert(AliasPack!(d.UnpackDeep).equals!(1, 4, 7, 
2, 5, 8, 3, 6, 9));

}
}

Cheers,
- Ali