[Issue 9621] std.conv.parseEscape fails on octals and named

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Mar 1 03:27:11 PST 2013


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



--- Comment #2 from monarchdodra at gmail.com 2013-03-01 03:27:10 PST ---
(In reply to comment #1)
> Is it documented anywhere that std.conv.parse should follow D lexer conventions
> on parsing??

Well it's kind of implied, isn't it? Why would parse follow a convention other
than D's ? No it's not documented, but I do remember somewhere in the threads
that Jonathan (I thin it was him), specifically saying that the idea is that it
allowed parsing pretty much anything that's valid D.

> If not I guess we shouldn't pretend it does and pull the whole freaking table
> of HTML4/5 entities in *every* program that uses parse to read a couple of
> ints.

I Disagree because the function *is* named parse, and is capable of parsing a
string, and returning the object parsed (in this case a string). If "\""
is a valid D string, then I'd expect parse to not choke on it.

As long as the user is parsing string to int, then no, he shouldn't need it,
but if the parse outcome is a string, there is no excuse to not do it right.

Shouldn't the fact that the table would only ever be used in a template
function (parse) mean the compiler should be able to know whether or not to
link with said table? Or would importing std.conv immediately link in the table
into the final executable?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list