On 01/04/2012 07:08 PM, deadalnix wrote:
Le 01/01/2012 23:46, Timon Gehr a écrit :
On 01/01/2012 11:36 PM, deadalnix wrote:
Le 31/12/2011 19:13, Timon Gehr a écrit :
On 12/31/2011 06:32 PM, Chad J wrote:
On 12/30/2011 05:27 PM, Timon Gehr wrote:
On 12/30/2011 10:36 PM, deadalnix wrote:
The
On 01/04/2012 11:31 PM, Timon Gehr wrote:
Code for which no tests exist is neither correct nor incorrect.
Assertions are a neat way to detect parts of the application whose
implementation is incomplete.
Another major use of them is the checked documentation of assumptions,
mainly in method pr
Le 01/01/2012 23:46, Timon Gehr a écrit :
On 01/01/2012 11:36 PM, deadalnix wrote:
Le 31/12/2011 19:13, Timon Gehr a écrit :
On 12/31/2011 06:32 PM, Chad J wrote:
On 12/30/2011 05:27 PM, Timon Gehr wrote:
On 12/30/2011 10:36 PM, deadalnix wrote:
The #1 quality of a programmer is to act like
On 01/01/2012 06:36 PM, Timon Gehr wrote:
> On 01/02/2012 12:16 AM, Chad J wrote:
>> On 01/01/2012 02:25 PM, Timon Gehr wrote:
>>> On 01/01/2012 08:01 PM, Chad J wrote:
On 01/01/2012 10:39 AM, Timon Gehr wrote:
> On 01/01/2012 04:13 PM, Chad J wrote:
>> On 01/01/2012 07:59 AM, Timon Ge
On 01/02/2012 12:16 AM, Chad J wrote:
On 01/01/2012 02:25 PM, Timon Gehr wrote:
On 01/01/2012 08:01 PM, Chad J wrote:
On 01/01/2012 10:39 AM, Timon Gehr wrote:
On 01/01/2012 04:13 PM, Chad J wrote:
On 01/01/2012 07:59 AM, Timon Gehr wrote:
On 01/01/2012 05:53 AM, Chad J wrote:
If you haven
On 01/01/2012 02:25 PM, Timon Gehr wrote:
> On 01/01/2012 08:01 PM, Chad J wrote:
>> On 01/01/2012 10:39 AM, Timon Gehr wrote:
>>> On 01/01/2012 04:13 PM, Chad J wrote:
On 01/01/2012 07:59 AM, Timon Gehr wrote:
> On 01/01/2012 05:53 AM, Chad J wrote:
>>
>> If you haven't been educa
On 01/01/2012 11:36 PM, deadalnix wrote:
Le 31/12/2011 19:13, Timon Gehr a écrit :
On 12/31/2011 06:32 PM, Chad J wrote:
On 12/30/2011 05:27 PM, Timon Gehr wrote:
On 12/30/2011 10:36 PM, deadalnix wrote:
The #1 quality of a programmer is to act like he/she is a morron.
Because sometime we al
Le 31/12/2011 19:13, Timon Gehr a écrit :
On 12/31/2011 06:32 PM, Chad J wrote:
On 12/30/2011 05:27 PM, Timon Gehr wrote:
On 12/30/2011 10:36 PM, deadalnix wrote:
The #1 quality of a programmer is to act like he/she is a morron.
Because sometime we all are morrons.
The #1 quality of a progr
On 01/01/2012 08:01 PM, Chad J wrote:
On 01/01/2012 10:39 AM, Timon Gehr wrote:
On 01/01/2012 04:13 PM, Chad J wrote:
On 01/01/2012 07:59 AM, Timon Gehr wrote:
On 01/01/2012 05:53 AM, Chad J wrote:
If you haven't been educated about unicode or how D handles it, you
might write this:
char[]
On 01/01/2012 10:39 AM, Timon Gehr wrote:
> On 01/01/2012 04:13 PM, Chad J wrote:
>> On 01/01/2012 07:59 AM, Timon Gehr wrote:
>>> On 01/01/2012 05:53 AM, Chad J wrote:
If you haven't been educated about unicode or how D handles it, you
might write this:
char[] str;
..
On 01/01/2012 04:13 PM, Chad J wrote:
On 01/01/2012 07:59 AM, Timon Gehr wrote:
On 01/01/2012 05:53 AM, Chad J wrote:
If you haven't been educated about unicode or how D handles it, you
might write this:
char[] str;
... load str ...
for ( int i = 0; i< str.length; i++ )
{
font.render(
On 01/01/2012 07:59 AM, Timon Gehr wrote:
> On 01/01/2012 05:53 AM, Chad J wrote:
>>
>> If you haven't been educated about unicode or how D handles it, you
>> might write this:
>>
>> char[] str;
>> ... load str ...
>> for ( int i = 0; i< str.length; i++ )
>> {
>> font.render(str[i]); // Ewww.
On 01/01/2012 08:10 AM, Don wrote:
On 31.12.2011 17:13, Timon Gehr wrote:
On 12/31/2011 01:15 PM, Don wrote:
On 31.12.2011 01:56, Timon Gehr wrote:
On 12/31/2011 01:12 AM, Andrei Alexandrescu wrote:
On 12/30/11 6:07 PM, Timon Gehr wrote:
alias std.string.representation raw;
I meant your im
On 01/01/2012 05:53 AM, Chad J wrote:
If you haven't been educated about unicode or how D handles it, you
might write this:
char[] str;
... load str ...
for ( int i = 0; i< str.length; i++ )
{
font.render(str[i]); // Ewww.
...
}
That actually looks like a bug that might happen in
> Meh, I'd still prefer it be an array of UTF-8 code /points/ represented
> by an array of bytes (which are the UTF-8 code units).
By saying you want an array of code points you already define
representation. And if you want that there already is dchar[]. You probably
meant a range of code points
On 31.12.2011 17:13, Timon Gehr wrote:
On 12/31/2011 01:15 PM, Don wrote:
On 31.12.2011 01:56, Timon Gehr wrote:
On 12/31/2011 01:12 AM, Andrei Alexandrescu wrote:
On 12/30/11 6:07 PM, Timon Gehr wrote:
alias std.string.representation raw;
I meant your implementation is incomplete.
It was
On 12/31/2011 09:17 PM, Timon Gehr wrote:
> On 01/01/2012 02:34 AM, Chad J wrote:
>> On 12/31/2011 02:02 PM, Timon Gehr wrote:
>>> On 12/31/2011 07:22 PM, Chad J wrote:
On 12/30/2011 02:55 PM, Timon Gehr wrote:
> On 12/30/2011 08:33 PM, Joshua Reusch wrote:
>>
>> Maybe it could hap
On 01/01/2012 02:34 AM, Chad J wrote:
On 12/31/2011 02:02 PM, Timon Gehr wrote:
On 12/31/2011 07:22 PM, Chad J wrote:
On 12/30/2011 02:55 PM, Timon Gehr wrote:
On 12/30/2011 08:33 PM, Joshua Reusch wrote:
Am 29.12.2011 19:36, schrieb Andrei Alexandrescu:
On 12/29/11 12:28 PM, Don wrote:
On
On 12/31/2011 02:02 PM, Timon Gehr wrote:
> On 12/31/2011 07:22 PM, Chad J wrote:
>> On 12/30/2011 02:55 PM, Timon Gehr wrote:
>>> On 12/30/2011 08:33 PM, Joshua Reusch wrote:
Am 29.12.2011 19:36, schrieb Andrei Alexandrescu:
> On 12/29/11 12:28 PM, Don wrote:
>> On 28.12.2011 20:00, A
Sorry, I was simplifying. The distinction I was trying to make was between
generic operations (in my experience the majority) vs. encoding-aware ones.
Sent from my iPhone
On Dec 31, 2011, at 12:48 PM, Michel Fortin wrote:
> On 2011-12-31 16:47:40 +, Sean Kelly said:
>
>> I don't know th
On 12/31/2011 07:56 PM, Andrei Alexandrescu wrote:
On 12/31/11 10:47 AM, Michel Fortin wrote:
This means you can't look at the frontUnit and then decide to pop the
unit and then look at the next, decide you need to decode using
frontPoint, then call popPoint and return to looking at the front un
On 12/31/11 2:44 PM, Michel Fortin wrote:
But will s.raw.popFront() also pop a single unit from s? "raw" would
need to be defined as a reinterpret cast of the reference to the char[]
to do what I want, something like this:
ref ubyte[] raw(ref char[] s) { return *cast(ubyte[]*)&s; }
The current
On 2011-12-31 16:47:40 +, Sean Kelly said:
I don't know that Unicode expertise is really required here anyway. All one
has to know is that UTF8 is a multibyte encoding and built-in string attrib
utes talk in bytes. Knowing when one wants bytes vs characters isn't rocket s
cience.
It's n
On 2011-12-31 18:56:01 +, Andrei Alexandrescu
said:
On 12/31/11 10:47 AM, Michel Fortin wrote:
It seems to work fine, but it doesn't
handle (yet) characters spanning multiple code points.
That's the job of std.range, not std.algorithm.
As I keep saying, if you handle combining code po
On 12/31/2011 08:06 PM, Andrei Alexandrescu wrote:
On 12/31/11 10:47 AM, Sean Kelly wrote:
I don't know that Unicode expertise is really required here anyway.
All one has to know is that UTF8 is a multibyte encoding and
built-in string attributes talk in bytes. Knowing when one wants
bytes vs ch
On 12/31/11 10:47 AM, Sean Kelly wrote:
I don't know that Unicode expertise is really required here anyway.
All one has to know is that UTF8 is a multibyte encoding and
built-in string attributes talk in bytes. Knowing when one wants
bytes vs characters isn't rocket science. That said, I'm on the
On 12/31/2011 07:22 PM, Chad J wrote:
On 12/30/2011 02:55 PM, Timon Gehr wrote:
On 12/30/2011 08:33 PM, Joshua Reusch wrote:
Am 29.12.2011 19:36, schrieb Andrei Alexandrescu:
On 12/29/11 12:28 PM, Don wrote:
On 28.12.2011 20:00, Andrei Alexandrescu wrote:
Oh, one more thing - one good thing
On 12/31/11 10:47 AM, Michel Fortin wrote:
On 2011-12-31 15:03:13 +, Andrei Alexandrescu
said:
On 12/31/11 8:17 CST, Michel Fortin wrote:
At one time Java and other frameworks started to use UTF-16 as
if they were characters, that turned wrong on them. Now we know that not
even code point
On 12/31/2011 01:13 PM, Timon Gehr wrote:
> On 12/31/2011 06:32 PM, Chad J wrote:
>> On 12/30/2011 05:27 PM, Timon Gehr wrote:
>>> On 12/30/2011 10:36 PM, deadalnix wrote:
The #1 quality of a programmer is to act like he/she is a morron.
Because sometime we all are morrons.
>>>
>>> T
On 12/30/2011 02:55 PM, Timon Gehr wrote:
> On 12/30/2011 08:33 PM, Joshua Reusch wrote:
>> Am 29.12.2011 19:36, schrieb Andrei Alexandrescu:
>>> On 12/29/11 12:28 PM, Don wrote:
On 28.12.2011 20:00, Andrei Alexandrescu wrote:
> Oh, one more thing - one good thing that could come out of th
On 12/31/2011 06:32 PM, Chad J wrote:
On 12/30/2011 05:27 PM, Timon Gehr wrote:
On 12/30/2011 10:36 PM, deadalnix wrote:
The #1 quality of a programmer is to act like he/she is a morron.
Because sometime we all are morrons.
The #1 quality of a programmer is to write correct code. If he/she a
On 12/30/2011 05:27 PM, Timon Gehr wrote:
> On 12/30/2011 10:36 PM, deadalnix wrote:
>>
>> The #1 quality of a programmer is to act like he/she is a morron.
>> Because sometime we all are morrons.
>
> The #1 quality of a programmer is to write correct code. If he/she acts
> as if he/she is a moron
On 2011-12-31 15:03:13 +, Andrei Alexandrescu
said:
On 12/31/11 8:17 CST, Michel Fortin wrote:
At one time Java and other frameworks started to use UTF-16 as
if they were characters, that turned wrong on them. Now we know that not
even code points should be considered characters, thanks t
I don't know that Unicode expertise is really required here anyway. All one
has to know is that UTF8 is a multibyte encoding and built-in string attributes
talk in bytes. Knowing when one wants bytes vs characters isn't rocket science.
That said, I'm on the fence about this change. It breaks co
I'm not sure I understand what's wrong with length. Of all the times I get a
length in one sizable i18nalized app at work I can think of only one instance
where I actually want the character count rather than the byte count. Is there
some other reason I'm not aware of that length is undesirable
On Saturday, 31 December 2011 at 15:03:13 UTC, Andrei
Alexandrescu wrote:
The whole concept of generic algorithms working on strings
efficiently
doesn't work.
Apparently std.algorithm does.
According to my research[1], std.array.replace (which uses
std.algorithm under the hood) can be at le
On 12/31/2011 03:17 PM, Michel Fortin wrote:
As for Walter being the only one coding by looking at the code units
directly, that's not true. All my parser code look at code units
directly and only decode to code points where necessary (just look at
the XML parsing code I posted a while ago to ge
On 12/31/2011 01:15 PM, Don wrote:
On 31.12.2011 01:56, Timon Gehr wrote:
On 12/31/2011 01:12 AM, Andrei Alexandrescu wrote:
On 12/30/11 6:07 PM, Timon Gehr wrote:
alias std.string.representation raw;
I meant your implementation is incomplete.
It was more a sketch than an implementation. I
Timon Gehr wrote:
Me too. I think the way we have it now is optimal. The only reason we
are discussing this is because of fear that uneducated users will write
code that does not take into account Unicode characters above code point
0x80.
+1
From D's string docs:
"char[] strings are in UTF-
On 12/31/11 8:17 CST, Michel Fortin wrote:
On 2011-12-31 08:56:37 +, Andrei Alexandrescu
said:
On 12/31/11 2:04 AM, Walter Bright wrote:
We're chasing phantoms here, and I worry a lot about over-engineering
trivia.
I disagree. I understand that seems trivia to you, but that doesn't
mak
On 2011-12-31 08:56:37 +, Andrei Alexandrescu
said:
On 12/31/11 2:04 AM, Walter Bright wrote:
We're chasing phantoms here, and I worry a lot about over-engineering
trivia.
I disagree. I understand that seems trivia to you, but that doesn't
make your opinion any less wrong, not to ment
On 31.12.2011 01:56, Timon Gehr wrote:
On 12/31/2011 01:12 AM, Andrei Alexandrescu wrote:
On 12/30/11 6:07 PM, Timon Gehr wrote:
alias std.string.representation raw;
I meant your implementation is incomplete.
It was more a sketch than an implementation. It is not even type safe :o).
But
Andrei Alexandrescu:
> We need .raw and we must abolish .length and [] for narrow strings.
I don't know if we need, but I agree those things are an improvement over the
current state.
To replace the disabled slicing I think something Python islice() will be
useful.
Bye,bear
bearophile
On 12/31/11 2:04 AM, Walter Bright wrote:
On 12/30/2011 11:09 PM, Andrei Alexandrescu wrote:
On 12/30/11 10:09 PM, Walter Bright wrote:
I'm not so sure about that. Timon Gehr's X macro tried to handle
UTF-8 correctly, but it turned out that the naive version that
used [i] and .length worked cor
2011/12/31 Walter Bright :
> On 12/30/2011 11:09 PM, Andrei Alexandrescu wrote:
>>
>> On 12/30/11 10:09 PM, Walter Bright wrote:
>>>
>>> I'm not so sure about that. Timon Gehr's X macro tried to handle UTF-8
>>> correctly, but it turned out that the naive version that used [i] and
>>> .length worke
On 12/30/2011 11:09 PM, Andrei Alexandrescu wrote:
On 12/30/11 10:09 PM, Walter Bright wrote:
I'm not so sure about that. Timon Gehr's X macro tried to handle UTF-8
correctly, but it turned out that the naive version that used [i] and
.length worked correctly. This is typical, not exceptional.
On Sat, Dec 31, 2011 at 12:09 AM, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:
> On 12/30/11 10:09 PM, Walter Bright wrote:
>
>> On 12/30/2011 7:30 PM, Jonathan M Davis wrote:
>>
>>> Yes, diligent programmers will generally find such problems, but with the
>>> current scheme, it's _
On 12/30/11 10:09 PM, Walter Bright wrote:
On 12/30/2011 7:30 PM, Jonathan M Davis wrote:
Yes, diligent programmers will generally find such problems, but with the
current scheme, it's _so_ easy to use length when you shouldn't, that
it's
pretty much a guarantee that it's going to happen.
I'm
On 12/30/2011 7:30 PM, Jonathan M Davis wrote:
Yes, diligent programmers will generally find such problems, but with the
current scheme, it's _so_ easy to use length when you shouldn't, that it's
pretty much a guarantee that it's going to happen.
I'm not so sure about that. Timon Gehr's X macro
On 12/31/2011 04:30 AM, Jonathan M Davis wrote:
On Friday, December 30, 2011 20:55:42 Timon Gehr wrote:
1. They don't notice. Then it is not a problem, because they are
obviously only using ASCII characters and it is perfectly reasonable to
assume that code units and characters are the same thin
On 2011-12-30 23:00:49 +, Andrei Alexandrescu
said:
Using .raw is /optimal/ because it states the assumption appropriately.
The user knows '$' cannot be in the prefix of any other symbol, so she
can state the byte alone is the character. If that were a non-ASCII
character, the assumption
On Friday, December 30, 2011 20:55:42 Timon Gehr wrote:
> 1. They don't notice. Then it is not a problem, because they are
> obviously only using ASCII characters and it is perfectly reasonable to
> assume that code units and characters are the same thing.
The problem is that what's more likely to
On 12/31/2011 01:12 AM, Andrei Alexandrescu wrote:
On 12/30/11 6:07 PM, Timon Gehr wrote:
alias std.string.representation raw;
I meant your implementation is incomplete.
It was more a sketch than an implementation. It is not even type safe :o).
But the main point is that presence of repre
On 12/30/11 6:07 PM, Timon Gehr wrote:
alias std.string.representation raw;
I meant your implementation is incomplete.
But the main point is that presence of representation/raw is not the
issue. The availability of good-for-nothing .length and operator[] are
the issue. Putting in place the c
On 12/31/2011 01:03 AM, Andrei Alexandrescu wrote:
On 12/30/11 5:07 PM, Timon Gehr wrote:
On 12/31/2011 12:00 AM, Andrei Alexandrescu wrote:
On 12/30/11 4:01 PM, Walter Bright wrote:
On 12/30/2011 11:55 AM, Timon Gehr wrote:
Me too. I think the way we have it now is optimal.
Consider your X
On 12/30/11 5:07 PM, Timon Gehr wrote:
On 12/31/2011 12:00 AM, Andrei Alexandrescu wrote:
On 12/30/11 4:01 PM, Walter Bright wrote:
On 12/30/2011 11:55 AM, Timon Gehr wrote:
Me too. I think the way we have it now is optimal.
Consider your X macro implementation. Strip out the utf.stride code
On 12/30/2011 3:00 PM, Andrei Alexandrescu wrote:
On 12/30/11 4:01 PM, Walter Bright wrote:
On 12/30/2011 11:55 AM, Timon Gehr wrote:
Me too. I think the way we have it now is optimal.
Consider your X macro implementation. Strip out the utf.stride code and
use plain indexing - it will not bre
On 12/31/2011 12:00 AM, Andrei Alexandrescu wrote:
On 12/30/11 4:01 PM, Walter Bright wrote:
On 12/30/2011 11:55 AM, Timon Gehr wrote:
Me too. I think the way we have it now is optimal.
Consider your X macro implementation. Strip out the utf.stride code and
use plain indexing - it will not br
On 12/30/11 4:01 PM, Walter Bright wrote:
On 12/30/2011 11:55 AM, Timon Gehr wrote:
Me too. I think the way we have it now is optimal.
Consider your X macro implementation. Strip out the utf.stride code and
use plain indexing - it will not break the code in any way. The naive
implementation st
On 12/30/2011 11:01 PM, Walter Bright wrote:
On 12/30/2011 11:55 AM, Timon Gehr wrote:
Me too. I think the way we have it now is optimal.
Consider your X macro implementation. Strip out the utf.stride code and
use plain indexing - it will not break the code in any way. The naive
implementation
On 12/30/2011 10:36 PM, deadalnix wrote:
Le 30/12/2011 20:55, Timon Gehr a écrit :
On 12/30/2011 08:33 PM, Joshua Reusch wrote:
Am 29.12.2011 19:36, schrieb Andrei Alexandrescu:
On 12/29/11 12:28 PM, Don wrote:
On 28.12.2011 20:00, Andrei Alexandrescu wrote:
Oh, one more thing - one good thi
On 12/30/2011 11:55 AM, Timon Gehr wrote:
Me too. I think the way we have it now is optimal.
Consider your X macro implementation. Strip out the utf.stride code and use
plain indexing - it will not break the code in any way. The naive implementation
still works correctly with ASCII and UTF-8.
Le 30/12/2011 20:55, Timon Gehr a écrit :
On 12/30/2011 08:33 PM, Joshua Reusch wrote:
Am 29.12.2011 19:36, schrieb Andrei Alexandrescu:
On 12/29/11 12:28 PM, Don wrote:
On 28.12.2011 20:00, Andrei Alexandrescu wrote:
Oh, one more thing - one good thing that could come out of this thread
is a
On 12/30/11 1:55 PM, Timon Gehr wrote:
Me too. I think the way we have it now is optimal.
What we have now is adequate. The scheme I proposed is optimal.
I agree with all of your other remarks.
Andrei
On Friday, 30 December 2011 at 19:55:45 UTC, Timon Gehr wrote:
I think the way we have it now is optimal. The only reason we
are discussing this is because of fear that uneducated users
will write code that does not take into account Unicode
characters above code point 0x80. But what is the wor
On 12/30/2011 08:33 PM, Joshua Reusch wrote:
Am 29.12.2011 19:36, schrieb Andrei Alexandrescu:
On 12/29/11 12:28 PM, Don wrote:
On 28.12.2011 20:00, Andrei Alexandrescu wrote:
Oh, one more thing - one good thing that could come out of this thread
is abolition (through however slow a deprecatio
Am 29.12.2011 19:36, schrieb Andrei Alexandrescu:
On 12/29/11 12:28 PM, Don wrote:
On 28.12.2011 20:00, Andrei Alexandrescu wrote:
Oh, one more thing - one good thing that could come out of this thread
is abolition (through however slow a deprecation path) of s.length and
s[i] for narrow string
this.
by the way, I don't want to blame someone, but I think we diverged from
the original purpose of this topic. __"string is rarely useful as a
function argument"__
I think he points out that choosing _string_ type in function arguments
is _wrong_ in most cases. and there isn't
On Thu, 29 Dec 2011 18:36:27 -, Andrei Alexandrescu
wrote:
On 12/29/11 12:28 PM, Don wrote:
On 28.12.2011 20:00, Andrei Alexandrescu wrote:
Oh, one more thing - one good thing that could come out of this thread
is abolition (through however slow a deprecation path) of s.length and
s[i]
On Thursday, December 29, 2011 17:01:19 deadalnix wrote:
> Le 28/12/2011 21:43, Jonathan M Davis a écrit :
> > Agreed. And for a number of functions, taking const(char)[] would be
> > worse, because they would have to dup or idup the string, whereas with
> > immutable(char)[], they can safely slice
On Thursday, December 29, 2011 11:32:52 Sean Kelly wrote:
> Don't we already have String-like support with ranges? I'm not sure I
> understand the point in having special behavior for char arrays.
To avoid common misusage. It's way to easy to misuse the length property on
narrow strings. Program
Don't we already have String-like support with ranges? I'm not sure I
understand the point in having special behavior for char arrays.
Sent from my iPhone
On Dec 28, 2011, at 8:17 PM, Andrei Alexandrescu
wrote:
> On 12/28/11 4:18 PM, foobar wrote:
>> On Wednesday, 28 December 2011 at 21:57:
On 12/29/11 12:28 PM, Don wrote:
On 28.12.2011 20:00, Andrei Alexandrescu wrote:
Oh, one more thing - one good thing that could come out of this thread
is abolition (through however slow a deprecation path) of s.length and
s[i] for narrow strings. Requiring s.rep.length instead of s.length and
s
On 28.12.2011 20:00, Andrei Alexandrescu wrote:
Oh, one more thing - one good thing that could come out of this thread
is abolition (through however slow a deprecation path) of s.length and
s[i] for narrow strings. Requiring s.rep.length instead of s.length and
s.rep[i] instead of s[i] would impr
On 12/29/2011 07:45 AM, foobar wrote:
On Wednesday, 28 December 2011 at 22:39:15 UTC, Timon Gehr wrote:
On 12/28/2011 11:12 PM, foobar wrote:
On Wednesday, 28 December 2011 at 21:17:49 UTC, Timon Gehr wrote:
I was educated enough not to make that mistake, because I read the
entire language sp
On 12/29/2011 07:53 AM, Walter Bright wrote:
On 12/28/2011 10:08 PM, Andrei Alexandrescu wrote:
The only solution is to explain Walter no other programmer in the
world codes
UTF like him. Really. I emulate that sometimes (learned from him) but
I see code
from hundreds of people day in and day ou
Le 29/12/2011 07:48, Jonathan M Davis a écrit :
On Thursday, December 29, 2011 07:33:28 Jakob Ovrum wrote:
I don't think this is a problem you can solve without educating
people. They will need to know a thing or two about how UTF works
to know the performance implications of many of the "safe"
Le 28/12/2011 21:43, Jonathan M Davis a écrit :
On Wednesday, December 28, 2011 10:27:15 Andrei Alexandrescu wrote:
I'm afraid you're wrong here. The current setup is very good, and much
better than one in which "string" would be an alias for const(char)[].
The problem is escaping. A function t
On Thursday, 29 December 2011 at 06:09:17 UTC, Andrei
Alexandrescu wrote:
Nah, that still breaks a lotta code because people parameterize
on T[], use isSomeString/isSomeChar etc.
/* snip struct string */
import std.traits;
void tem(T)(T t) if(isSomeString!T) {}
void tem2(T : immutable(char)[])
On 12/29/11 2:04 AM, Vladimir Panteleev wrote:
I think it would be simpler to just make dstring the default string type.
dstring is simple and safe. People who want better memory usage can use
UTF-8 at their own discretion.
memory == time
Andrei
oops. I accidentally made a recursive call in the setter. scratch
that, it should change the attribute.
On Thu, Dec 29, 2011 at 6:58 PM, Gor Gyolchanyan
wrote:
> What if the string converted itself from utf-8 to utf-32 back and
> forth as necessary (utf-8 for storing and utf-32 for processing):
>
What if the string converted itself from utf-8 to utf-32 back and
forth as necessary (utf-8 for storing and utf-32 for processing):
struct String
{
public:
bool encoded() @property const
{
return _encoded;
}
bool encoded(bool should) @property
{
if(should)
On 12/29/2011 12:12 AM, Gor Gyolchanyan wrote:
This a a great idea! In this case the default string will be a
random-access range, not a bidirectional range. Also, processing
dstring is faster, then string, because no encoding needs to be done.
Processing power is more expensive, then memory. utf
On Thu, 29 Dec 2011 16:36:59 +1100, Walter Bright
wrote:
I've seen the damage done in C++ with multiple string types. Being able
to convert from one to the other doesn't help much.
I'm not quite sure about that last sentence. I suspect that the better way
for applications to handle strin
This a a great idea! In this case the default string will be a
random-access range, not a bidirectional range. Also, processing
dstring is faster, then string, because no encoding needs to be done.
Processing power is more expensive, then memory. utf-8 is valuable
only to pass it as an ASCII string
On Wednesday, 28 December 2011 at 19:00:53 UTC, Andrei
Alexandrescu wrote:
On 12/28/11 12:46 PM, Walter Bright wrote:
On 12/28/2011 10:35 AM, Peter Alexander wrote:
On 28/12/11 6:15 PM, Walter Bright wrote:
If such a change is made, then people will use const string
when they
mean immutable, a
On 12/28/2011 10:33 PM, Jakob Ovrum wrote:
I don't think this is a problem you can solve without educating people. They
will need to know a thing or two about how UTF works to know the performance
implications of many of the "safe" ways to handle UTF strings. Further, for much
use of Unicode stri
On 12/28/2011 10:08 PM, Andrei Alexandrescu wrote:
The only solution is to explain Walter no other programmer in the world codes
UTF like him. Really. I emulate that sometimes (learned from him) but I see code
from hundreds of people day in and day out - it's never like his.
Once we convince him
On Wednesday, 28 December 2011 at 22:39:15 UTC, Timon Gehr wrote:
On 12/28/2011 11:12 PM, foobar wrote:
On Wednesday, 28 December 2011 at 21:17:49 UTC, Timon Gehr
wrote:
I was educated enough not to make that mistake, because I
read the
entire language specification before deciding the langua
On Thursday, December 29, 2011 07:33:28 Jakob Ovrum wrote:
> I don't think this is a problem you can solve without educating
> people. They will need to know a thing or two about how UTF works
> to know the performance implications of many of the "safe" ways
> to handle UTF strings. Further, for mu
On Thursday, 29 December 2011 at 06:08:05 UTC, Andrei
Alexandrescu wrote:
On 12/28/11 11:36 PM, Walter Bright wrote:
On 12/28/2011 8:32 PM, Adam D. Ruppe wrote:
On Thursday, 29 December 2011 at 04:17:37 UTC, Andrei
Alexandrescu wrote:
If we have two facilities (string and e.g. String) we've
lo
On 12/29/11 12:01 AM, Adam D. Ruppe wrote:
On Thursday, 29 December 2011 at 05:37:00 UTC, Walter Bright wrote:
I've seen the damage done in C++ with multiple string types. Being
able to convert from one to the other doesn't help much.
Note that I'm on your side here re strings, but you're
unde
On 12/28/11 11:36 PM, Walter Bright wrote:
On 12/28/2011 8:32 PM, Adam D. Ruppe wrote:
On Thursday, 29 December 2011 at 04:17:37 UTC, Andrei Alexandrescu wrote:
If we have two facilities (string and e.g. String) we've lost. We'd
need to
slowly change the built-in string type.
Have you actuall
On Thursday, 29 December 2011 at 05:37:00 UTC, Walter Bright
wrote:
I've seen the damage done in C++ with multiple string types.
Being able to convert from one to the other doesn't help much.
Note that I'm on your side here re strings, but you're
underselling the D language too! These conversio
On 12/28/2011 8:32 PM, Adam D. Ruppe wrote:
On Thursday, 29 December 2011 at 04:17:37 UTC, Andrei Alexandrescu wrote:
If we have two facilities (string and e.g. String) we've lost. We'd need to
slowly change the built-in string type.
Have you actually tried to do it?
I've seen the damage don
On Thursday, 29 December 2011 at 04:17:37 UTC, Andrei
Alexandrescu wrote:
If we have two facilities (string and e.g. String) we've lost.
We'd need to slowly change the built-in string type.
Have you actually tried to do it? Thanks to alias this, the custom
string can be used with existing std.s
On 12/28/11 4:18 PM, foobar wrote:
On Wednesday, 28 December 2011 at 21:57:00 UTC, Andrei Alexandrescu wrote:
On 12/28/11 1:48 PM, foobar wrote:
On Wednesday, 28 December 2011 at 19:30:04 UTC, Andrei Alexandrescu
wrote:
On 12/28/11 1:18 PM, foobar wrote:
That's a good idea which I wonder abou
Andrei Alexandrescu:
> one good thing that could come out of this thread
> is abolition (through however slow a deprecation path) of s.length and
> s[i] for narrow strings. Requiring s.rep.length instead of s.length and
> s.rep[i] instead of s[i] would improve the quality of narrow strings
> treme
On Wed, 28 Dec 2011 14:06:06 +0200, Peter Alexander
wrote:
string is immutable(char)[]
I rarely *ever* need an immutable string. What I usually need is
const(char)[]. I'd say 99%+ of the time I need only a const string.
This is quite irritating because "string" is the most convenient and
On 12/28/2011 11:12 PM, foobar wrote:
On Wednesday, 28 December 2011 at 21:17:49 UTC, Timon Gehr wrote:
I was educated enough not to make that mistake, because I read the
entire language specification before deciding the language was awesome
and downloading the compiler. I find it strange that
1 - 100 of 153 matches
Mail list logo
