Let's stop parser Hell
Jacob Carlborg
doob at me.com
Wed Aug 1 23:36:11 PDT 2012
On 2012-08-01 22:10, Jonathan M Davis wrote:
> It may very well be a good idea to templatize Token on range type. It would be
> nice not to have to templatize it, but that may be the best route to go. The
> main question is whether str is _always_ a slice (or the result of
> takeExactly) of the orignal range. I _think_ that it is, but I'd have to make
> sure of that. If it's not and can't be for whatever reason, then that poses a
> problem. If Token _does_ get templatized, then I believe that R will end up
> being the original type in the case of the various string types or a range
> which has slicing, but it'll be the result of takeExactly(range, len) for
> everything else.
To me a string type would be enough. I don't need support for ranges.
How about adding a union instead?
enum StringType
{
utf8,
utf16,
utf32
}
struct Token
{
StringType stringType;
union
{
string strc;
wstring strw;
dstring strd;
}
@property T str (T = string) ()
{
static if (is(T == string))
{
assert(stringType == StringType.utf8);
return strc;
}
...
}
}
Most use cases would look like this:
string s = token.str;
> I just made str a string to begin with, since it was simple, and I was still
> working on a lot of the initial design and how I was going to go about things.
> If it makes more sense for it to be templated, then it'll be changed so that
> it's templated.
I completely understand that.
--
/Jacob Carlborg
More information about the Digitalmars-d
mailing list