[Issue 2201] Doc/Behavior Discrepancy: EndOfLine in string turns to "\n" or system-specific?

d-bugmail at puremagic.com d-bugmail at puremagic.com
Tue Jul 8 10:22:44 PDT 2008


http://d.puremagic.com/issues/show_bug.cgi?id=2201





------- Comment #5 from business3 at twistedpairgaming.com  2008-07-08 12:22 -------
(In reply to comment #4)
> I think theres some verbiage to the effect of the current behavior (but applied
> to the language text as a whole) Copy/Paste that in there or maybe even just
> drop the above quoted all together and I think this can be closed.

I don't see anything like that. You might be thinking of the definition of
EndOfLine (quoted above).

> Also, (untested) I think this edit will make it work:
> 
> mixin(makeStrReturnFunc("carriageReturn", "\r"));
> mixin(makeStrReturnFunc("carriageReturn", r"\r"));
> 
> you might need to drop the r in the mixin maker as well.

That changes the content of the generated function from:

return r"
"; // <- Intended CR inside, not CRLF

To:

return "\r";

That does work, but:

1. It's not a demonstration of an embedded CR (so it doesn't solve the
doc/behavior discrepancy).

2. It causes the caller of makeStrReturnFunc to double-escape everything (r"\r"
and "\\r" suddenly mean CR instead of meaning ['\\', 'r'], and if ['\\', 'r']
is desired, you need r"\\r" or "\\\\r"), which is what I was trying to prevent
by making the generated function return ...r"~data~"... instead of
..."~data~".... But like I've said before, that could be solved when/if
escapeString(strToBeEscaped) is doable at compile-time (ie, make it return
..."~escapeString(data)~"... instead of ...r"~data~"...).


-- 



More information about the Digitalmars-d-bugs mailing list