On Wed, Nov 28, 2012 at 10:40 PM, Daniel N <ufo@orbiting.us> wrote:
Thanks to the wonderful UDA implementation in 2.061, I thought of a little hack, which may interest at least someone.

I'm using it for prototyping ctfe ast transformations together with: https://github.com/PhilippeSigaud/Pegged

Aha!
 

Yes, it was possible to do similar stuff before and "examples/dgrammar.d" from Pegged is quite impressive, but not bug free.

No kidding :)
I've a few contributors who're helping me stabilize / make the engine better. We will tackle the D grammar afterwards. It does make a good testing ground for when I want to push the CTFE throttle.

 
This UDA-line-hack-way is actually significantly cleaner, because when using __LINE__ you are certain that there will be at least one [__LINE__] which is not inside a string or comment on the attributed line... this allows one to make a very limited grammar/parser which doesn't have to know/parse/understand the entire file.

I don't understand what you're trying to do. Could you please explain it a bit more? UDA's a quite new and I'd be very interested in their interaction with compile-time code manipulation.



If anyone else have fun UDA hacks, considering that it's a new feature, please share.

import std.string;
import std.range;

struct magic
{
  [__LINE__] int var1;
  [__LINE__] int var2;
  [__LINE__] int var3;
}

enum dsrc = import(__FILE__).splitLines(KeepTerminator.yes);

string parse()
{
  string result = "";

  foreach(m; __traits(allMembers, magic))
    result ~= dsrc.drop(__traits(getAttributes, mixin("magic." ~ m))[0]-1).takeOne().front;

What I don't get is how the [__LINE__] part in magic contains significant info.