On 2011-06-16 12:51, Jouko Koski wrote:
> "Jonathan M Davis" wrote:
> > On 2011-06-14 11:53, Jouko Koski wrote:
> >> I would not consider it being good idea to include this kind of
> >> ascii-only
> >> utilities in the standard-ish library.
> >
> > For some classes of operations, it makes perfect
"Jonathan M Davis" wrote:
On 2011-06-14 11:53, Jouko Koski wrote:
I would not consider it being good idea to include this kind of
ascii-only
utilities in the standard-ish library.
For some classes of operations, it makes perfect sense to be checking for
ASCII characters only. For others,
On Tue, 14 Jun 2011 10:20:48 +0100, Jonathan M Davis
wrote:
So, given the arguably poor name of ctype and the fact that std.ctype
does not actually match ctype.h's behavior, unless someone comes up with
a really good reason not to fairly soon, I'm going to schedule std.ctype
for deprecat
On 2011-06-14 11:53, Jouko Koski wrote:
> "Jonathan M Davis" wrote:
> > So, yes I understood. It's just that as far as I can tell, locales don't
>
> matter if you're completely restricting yourself to ASCII like std.ctype
> does.
>
> I would not consider it being good idea to include this kind o
Am 14.06.2011 21:29, schrieb Timon Gehr:
> Daniel Gibson wrote:
>> Am 14.06.2011 20:58, schrieb Andrej Mitrovic:
>>> Why does std.ctype exist anyway? Can't you use std.uni for both ASCII
>>> and UTF? Or is there some overhead in using the uni functions?
>>
>> I haven't looked at either implementati
Daniel Gibson wrote:
> Am 14.06.2011 20:58, schrieb Andrej Mitrovic:
>> Why does std.ctype exist anyway? Can't you use std.uni for both ASCII
>> and UTF? Or is there some overhead in using the uni functions?
>
> I haven't looked at either implementation, but on ASCII everything is
> really simple..
Am 14.06.2011 20:58, schrieb Andrej Mitrovic:
> Why does std.ctype exist anyway? Can't you use std.uni for both ASCII
> and UTF? Or is there some overhead in using the uni functions?
I haven't looked at either implementation, but on ASCII everything is
really simple.. isalpha, isdigit, isupper and
Why does std.ctype exist anyway? Can't you use std.uni for both ASCII
and UTF? Or is there some overhead in using the uni functions?
"Jonathan M Davis" wrote:
So, yes I understood. It's just that as far as I can tell, locales don't
matter if you're completely restricting yourself to ASCII like std.ctype
does.
I would not consider it being good idea to include this kind of ascii-only
utilities in the standard-ish library.
On 2011-06-14 02:51, David Nadlinger wrote:
> On 6/14/11 11:20 AM, Jonathan M Davis wrote:
> > On 2011-06-14 01:51, David Nadlinger wrote:
> >> But the functions in do. And there can be some
> >> locale-dependent problems even if you use only ASCII, the most prominent
> >> being the different hand
On 6/14/11 11:20 AM, Jonathan M Davis wrote:
On 2011-06-14 01:51, David Nadlinger wrote:
But the functions in do. And there can be some
locale-dependent problems even if you use only ASCII, the most prominent
being the different handling of »i« in the Turkish locale:
http://www.i18nguy.com/unic
On 2011-06-14 01:51, David Nadlinger wrote:
> On 6/14/11 8:23 AM, Jonathan M Davis wrote:
> >> What is your definition for ASCII character?
> >>
> >> Most of the functions (or macros) are locale dependent, see
> >> setlocale() and. And there is the, too.
> >>
> >> While the C standardized ways o
On 6/14/11 8:23 AM, Jonathan M Davis wrote:
What is your definition for ASCII character?
Most of the functions (or macros) are locale dependent, see
setlocale() and. And there is the, too.
While the C standardized ways of doing things might not be most appropriate
approach in D domain, we must
On Jun 14, 11 14:23, Jonathan M Davis wrote:
On 2011-06-13 22:48, Jouko Koski wrote:
"Jonathan M Davis" wrote:
std.ctype is modeled after C's ctype.h. It has functions for operating on
characters - particularly functions which indicate the type of a
character (I
believe that ctype stands for c
On 2011-06-13 22:48, Jouko Koski wrote:
> "Jonathan M Davis" wrote:
> > std.ctype is modeled after C's ctype.h. It has functions for operating on
> > characters - particularly functions which indicate the type of a
> > character (I
> > believe that ctype stands for character type, so that makes se
"Jonathan M Davis" wrote:
std.ctype is modeled after C's ctype.h. It has functions for operating on
characters - particularly functions which indicate the type of a character
(I
believe that ctype stands for character type, so that makes sense). For
instance, isdigit will tell you whether a p
Come to think of it, I think I had a note in a todo somewhere that
said "post a feature request to change ctype to ascii". It's a good
standard name.
I'm all for it. I've never liked ctype, and I got lost trying to find
ascii functions since I didn't know where to look. The first time I
saw ctype I thought it was a collection of C type aliases.. heh.
t to making those changes is essentially the same
> > whether we replace the whole std.ctype module or whether we replace all
> > of its functions, I'm wondering whether it would be worthwhile to take
> > this opportunity to rename std.ctype?
> >
> > I don't thin
e is enough of an improvement to do it if
> it's going to break everyone's code, but given that fixing all of its
> functions gives us a perfect opportunity to rename it at no additional cost, I
> feel that the question should be posed.
>
> Should we rename std.ctype to std.ascii? Or should we just keep the old name,
> which is familiar to C programmers?
>
> - Jonathan M Davis
>
or deprecate std.ctype and create a new std.ascii.
pe?
I don't think that the name change is enough of an improvement to do it if
it's going to break everyone's code, but given that fixing all of its
functions gives us a perfect opportunity to rename it at no additional cost, I
feel that the question should be posed.
Should
21 matches
Mail list logo
