On Wed, 18 Aug 2010 23:11:26 -0400, Rainer Deyke rain...@eldwood.com
wrote:
On 8/18/2010 20:37, dsimcha wrote:
I've been hacking in Phobos and parallelfuture and I've come to the
conclusion
that having typeof(c) in the expression foreach(c; string.init) not be
a dchar
is simply
On Thu, 19 Aug 2010 10:34:01 -0400, dsimcha dsim...@yahoo.com wrote:
== Quote from Kagamin (s...@here.lot)'s article
dsimcha Wrote:
Hmm, lately I've been focusing my hacking efforts on
debugging/polishing/removing
annoying inconsistencies in Phobos. Maybe std.string should be my
next
Rainer Deyke rain...@eldwood.com wrote:
On 8/19/2010 03:56, Jonathan Davis wrote:
The problem is that chars are not characters. They are UTF-8 code
units.
So what? You're acting like 'char' (and specifically 'char[]') is some
sort of unique special case. In reality, it's just one case of
On Friday, August 20, 2010 09:44:26 Simen kjaeraas wrote:
Rainer Deyke rain...@eldwood.com wrote:
On 8/19/2010 03:56, Jonathan Davis wrote:
The problem is that chars are not characters. They are UTF-8 code
units.
So what? You're acting like 'char' (and specifically 'char[]') is some
On 08/20/2010 12:22 PM, Jonathan M Davis wrote:
On Friday, August 20, 2010 09:44:26 Simen kjaeraas wrote:
Rainer Deykerain...@eldwood.com wrote:
On 8/19/2010 03:56, Jonathan Davis wrote:
The problem is that chars are not characters. They are UTF-8 code
units.
So what? You're acting like
Jonathan M Davis Wrote:
Everywhere in the code where you currently have string, you'd have
String(immutable char) instead of immutable (char)[].
Not necessarily. I think, you can leave std.algorithm string-agnostic and
special case string operations in, say, std.string, which will take and
Jonathan M Davis Wrote:
Trivial: take byte and add 256.
If you want to change the iteration type to int or
long or whatever when iterating over bytes so that you can change the
variable
without overflow issues, you can. But the byte itself is meaingful by itself.
Such is not
On 8/20/2010 10:44, Simen kjaeraas wrote:
First off, char, wchar, and dchar are special cases already - they're
basically byte, short, and int, but are treated somewhat differently.
They're only special cases when placed in a built-in array. In any
other container, they behave like normal
dsimcha Wrote:
If D is at all serious about generic programming, we simply can't require this
to be dealt with **everywhere** as a special case.
Just remove the special case of automatic conversion from strings to dchar[]
and you will have one less surprize. After all, it was a deliberate
dsimcha Wrote:
If D is at all serious about generic programming, we simply can't require this
to be dealt with **everywhere** as a special case.
I suspect, ranges were designed for FP, so use map instead of foreach. Or fold.
Or another 3-letter abbreviation. This will give you a possibility
Jonathan M Davis Wrote:
Considering that in all likelihood 99+% of the cases where someone is
iterating
over char, they really want dchar
And when someone is iterating over byte[] or short[], they want long, right?
Yeah, why not?
On 08/19/2010 04:37 AM, dsimcha wrote:
I've been hacking in Phobos and parallelfuture and I've come to the conclusion
that having typeof(c) in the expression foreach(c; string.init) not be a dchar
is simply ridiculous. I don't care how much existing code gets broken, this
needs to be fixed.
On 8/19/10, Kagamin s...@here.lot wrote:
Jonathan M Davis Wrote:
Considering that in all likelihood 99+% of the cases where someone is
iterating
over char, they really want dchar
And when someone is iterating over byte[] or short[], they want long, right?
Yeah, why not?
The problem is
On 2010-08-18 22:37:04 -0400, dsimcha dsim...@yahoo.com said:
If D is at all serious about generic programming, we simply can't require this
to be dealt with **everywhere** as a special case.
I do agree that the current special case situation is pretty bad.
Foreach really need to use
== Quote from dsimcha (dsim...@yahoo.com)'s article
I've been hacking in Phobos and parallelfuture and I've come to the conclusion
that having typeof(c) in the expression foreach(c; string.init) not be a dchar
is simply ridiculous.
BTW, what are some examples of where making dchar the default
Jonathan Davis Wrote:
bytes and shorts are legitimate values on their own, so it wouldn't
make sense to give the type to foreach as long.
Having wider integer always has sense.
byte or short on its own just fine.
Yes, but odds are that it's a bug. You can easily hit an overflow.
So, it's
== Quote from dsimcha (dsim...@yahoo.com)'s article
I've been hacking in Phobos and parallelfuture and I've come to the conclusion
that having typeof(c) in the expression foreach(c; string.init) not be a dchar
is simply ridiculous. I don't care how much existing code gets broken, this
needs
== Quote from Kagamin (s...@here.lot)'s article
Jonathan Davis Wrote:
bytes and shorts are legitimate values on their own, so it wouldn't
make sense to give the type to foreach as long.
Having wider integer always has sense.
byte or short on its own just fine.
Yes, but odds are that it's
dsimcha Wrote:
BTW, what are some examples of where making dchar the default would
**silently**
break code?
1. Read a file and cast the buffer to string.
2. Surprising difference in string lenghts that were just checked.
dsimcha Wrote:
Hmm, lately I've been focusing my hacking efforts on
debugging/polishing/removing
annoying inconsistencies in Phobos. Maybe std.string should be my next
target.
It's generally a frustrating module because in addition to the wide character
issue, lots of stuff requires
== Quote from Kagamin (s...@here.lot)'s article
dsimcha Wrote:
Hmm, lately I've been focusing my hacking efforts on
debugging/polishing/removing
annoying inconsistencies in Phobos. Maybe std.string should be my next
target.
It's generally a frustrating module because in addition to
dsimcha dsim...@yahoo.com wrote:
I've been hacking in Phobos and parallelfuture and I've come to the
conclusion
that having typeof(c) in the expression foreach(c; string.init) not be a
dchar
is simply ridiculous. I don't care how much existing code gets broken,
this
needs to be fixed.
On Thursday, August 19, 2010 07:13:25 Kagamin wrote:
Jonathan Davis Wrote:
bytes and shorts are legitimate values on their own, so it wouldn't
make sense to give the type to foreach as long.
Having wider integer always has sense.
byte or short on its own just fine.
Yes, but odds are
On Thursday, August 19, 2010 07:15:30 dsimcha wrote:
== Quote from dsimcha (dsim...@yahoo.com)'s article
I've been hacking in Phobos and parallelfuture and I've come to the
conclusion that having typeof(c) in the expression foreach(c;
string.init) not be a dchar is simply ridiculous. I
Jonathan M Davis Wrote:
No, it doesn't hurt to have the iteration type larger than the actual type,
but
you're not going to have overflow.
Trivial: take byte and add 256.
could have had overflow putting it in, but when you're taking it out, you
know
that it fits because it was already
Jonathan M Davis Wrote:
Not to mention, the Linux I/O stuff uses UTF-8, and
the Windows I/O stuff uses UTF-16, so dstring is less efficient for dealing
with
I/O.
If we take dil as an example of application doing much of string processing.
How much string processing it does and how
On Thursday, August 19, 2010 12:18:03 Kagamin wrote:
Jonathan M Davis Wrote:
No, it doesn't hurt to have the iteration type larger than the actual
type, but you're not going to have overflow.
Trivial: take byte and add 256.
Except that that only happens once you do something to the
On Thursday, August 19, 2010 12:24:22 Kagamin wrote:
Jonathan M Davis Wrote:
Not to mention, the Linux I/O stuff uses UTF-8, and
the Windows I/O stuff uses UTF-16, so dstring is less efficient for
dealing with I/O.
If we take dil as an example of application doing much of string
On 8/19/2010 03:56, Jonathan Davis wrote:
The problem is that chars are not characters. They are UTF-8 code
units.
So what? You're acting like 'char' (and specifically 'char[]') is some
sort of unique special case. In reality, it's just one case of encoded
data. What about compressed data?
== Quote from Rainer Deyke (rain...@eldwood.com)'s article
On 8/19/2010 03:56, Jonathan Davis wrote:
The problem is that chars are not characters. They are UTF-8 code
units.
So what? You're acting like 'char' (and specifically 'char[]') is some
sort of unique special case. In reality,
I've been hacking in Phobos and parallelfuture and I've come to the conclusion
that having typeof(c) in the expression foreach(c; string.init) not be a dchar
is simply ridiculous. I don't care how much existing code gets broken, this
needs to be fixed. Otherwise, all generic code will have to
On Wednesday 18 August 2010 19:37:04 dsimcha wrote:
I've been hacking in Phobos and parallelfuture and I've come to the
conclusion that having typeof(c) in the expression foreach(c; string.init)
not be a dchar is simply ridiculous. I don't care how much existing code
gets broken, this needs
On 8/18/2010 20:37, dsimcha wrote:
I've been hacking in Phobos and parallelfuture and I've come to the conclusion
that having typeof(c) in the expression foreach(c; string.init) not be a dchar
is simply ridiculous.
I have long ago come to the opposite conclusion. An array of 'char'
should act
On 8/18/2010 21:12, Jonathan M Davis wrote:
The one thing about it that bugs me is that it means
that foreach acts differently with chars and wchars then it does with
everything
else, but really, that's a _lot_ less of an issue than the problems that you
get
with generic programming
34 matches
Mail list logo
