This odd post comes from reading the nice part about strings of chapter 4 of
TDPL. In the last few years I have seen changes in how D strings are meant and
managed, changes that make them less and less like arrays (random-access
sequences of mutable code units) and more and more what they are at
> 5) foreach(c; s1) yields a code point dchars regardless if s1 is string,
dstring, wstring.
> But you can use foreach(char c; s1) if s1 is a string and you are sure s1 uses
only 7 bit chars. But in such cases you can also use a immutable(ubyte)[].
Python3
does something similar, its has a str typ
%u:
> When you are working with individual characters you almost always want either
> a
> dchar or a byte.
A dchar and an ubyte are better. This is almost what Python3 does and I think
it can be good. Maybe other people will give their opinions about my original
post.
Bye,
bearophile
bearophile wrote:
This odd post comes from reading the nice part about strings of chapter 4 of
TDPL. In the last few years I have seen changes in how D strings are meant
and managed, changes that make them less and less like arrays (random-access
sequences of mutable code units) and more and more
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> bearophile wrote:
> > This odd post comes from reading the nice part about strings of chapter 4 of
> > TDPL. In the last few years I have seen changes in how D strings are meant
> > and managed, changes that make them less and les
On Mon, 19 Jul 2010 16:04:21 -0400, Walter Bright
wrote:
bearophile wrote:
This odd post comes from reading the nice part about strings of chapter
4 of
TDPL. In the last few years I have seen changes in how D strings are
meant
and managed, changes that make them less and less like arrays
Walter Bright:
> 1. most string operations, such as copying and searching, even regular
> expressions, work just fine using regular indices.
>
> 2. doing the operations in (1) using code points and having to continually
> decode the strings would result in disastrously slow code.
In my original
Pragmatically, I seem to have noted that in languages with low level strings,
people invariably come up with librairies that provide higher-level strings.
C/C++ provided low-level strings only initially, then a not-so-powerful
std::string; and we saw QString, wxString, irr::string, BetterString,
What about:
struct String {
string items;
alias items this;
}
And add the needed functions you wish to have in string and it will still work
in existing functions that operate on immutable(char)[]
On Monday, July 19, 2010 16:49:58 Marianne Gagnon wrote:
> Pragmatically, I seem to have noted that in languages with low level
> strings, people invariably come up with librairies that provide
> higher-level strings. C/C++ provided low-level strings only initially,
> then a not-so-powerful std::st
On 07/19/2010 06:51 PM, Jesse Phillips wrote:
What about:
struct String {
string items;
alias items this;
}
And add the needed functions you wish to have in string and it will still work
in existing functions that operate on immutable(char)[]
Fortunately you can essentially a
bearophile wrote:
Walter Bright:
1. most string operations, such as copying and searching, even regular
expressions, work just fine using regular indices.
2. doing the operations in (1) using code points and having to continually
decode the strings would result in disastrously slow code.
In
Steven Schveighoffer wrote:
On Mon, 19 Jul 2010 16:04:21 -0400, Walter Bright
wrote:
Strings in D are deliberately meant to be arrays, not special things.
Other languages make them special because they have insufficiently
powerful arrays.
Andrei is changing that. Already, isRandomAccessRang
On 07/19/2010 11:31 PM, Walter Bright wrote:
Steven Schveighoffer wrote:
On Mon, 19 Jul 2010 16:04:21 -0400, Walter Bright
wrote:
Strings in D are deliberately meant to be arrays, not special things.
Other languages make them special because they have insufficiently
powerful arrays.
Andrei i
On 07/19/2010 11:29 PM, Walter Bright wrote:
bearophile wrote:
Walter Bright:
1. most string operations, such as copying and searching, even
regular expressions, work just fine using regular indices.
2. doing the operations in (1) using code points and having to
continually
decode the strings
On Tue, 20 Jul 2010 01:51:51 +0200, Jesse Phillips
wrote:
What about:
struct String {
string items;
alias items this;
}
And add the needed functions you wish to have in string and it will
still work in existing functions that operate on immutable(char)[]
You shouldn't ne
Walter:
>As it turns out, indexing by byte is *far* more common than indexing by code
>unit, in fact, I've never ever needed to index by code unit.<
OK.
>Probably too late to change that one.
There is very little D2 code around, so little changes as this one are possible
still. As alternativ
On 2010-07-20 00:31:34 -0400, Walter Bright said:
Steven Schveighoffer wrote:
I agree here. Anything that uses indexing to perform a linear
operation is bound for the scrap heap. But what about this:
foreach(c; str)
which types c as char (or immutable char), not dchar.
Probably too late
== Quote from Michel Fortin (michel.for...@michelf.com)'s article
> On 2010-07-20 00:31:34 -0400, Walter Bright
said:
> > Steven Schveighoffer wrote:
> >> I agree here. Anything that uses indexing to perform a linear
> >> operation is bound for the scrap heap. But what about this:
> >>
> >> fore
On Mon, 19 Jul 2010 20:26:47 -0400, Andrei Alexandrescu
wrote:
On 07/19/2010 06:51 PM, Jesse Phillips wrote:
What about:
struct String {
string items;
alias items this;
}
And add the needed functions you wish to have in string and it will
still work in existing functions
On Tue, 20 Jul 2010 16:08:06 +0200, Jesse Phillips
wrote:
But then you can't overload operators.
On Tue, Jul 20, 2010 at 12:54 AM, Rory McGuire
wrote:
On Tue, 20 Jul 2010 01:51:51 +0200, Jesse Phillips
wrote:
What about:
struct String {
string items;
alias items this;
}
On Tue, 20 Jul 2010 16:51:57 +0200, Rory McGuire
wrote:
On Tue, 20 Jul 2010 16:08:06 +0200, Jesse Phillips
wrote:
But then you can't overload operators.
On Tue, Jul 20, 2010 at 12:54 AM, Rory McGuire
wrote:
On Tue, 20 Jul 2010 01:51:51 +0200, Jesse Phillips
wrote:
What about:
st
Steven Schveighoffer Wrote:
>
> How do we make this work?
>
> auto str = "hello world";
> foreach(c; str)
> assert(is(typeof(c) == dchar));
foreach (dchar c; str)
assert(...);
This feature has been in D for years.
Walter Bright Wrote:
> bearophile wrote:
> > Walter Bright:
> >> 1. most string operations, such as copying and searching, even regular
> >> expressions, work just fine using regular indices.
> >>
> >> 2. doing the operations in (1) using code points and having to continually
> >> decode the st
Rory McGuire wrote:
[snip]
Rory, is there something wrong with your newsreader? I keep seeing your
posts as replies only to the top post.
--
Simen
Sean Kelly wrote:
> Steven Schveighoffer Wrote:
>> How do we make this work?
>>
>> auto str = "hello world";
>> foreach(c; str)
>> assert(is(typeof(c) == dchar));
>
> foreach (dchar c; str)
> assert(...);
>
> This feature has been in D for years.
And what about this one:
void fu
Simen kjaeraas Wrote:
> Rory McGuire wrote:
>
> [snip]
>
> Rory, is there something wrong with your newsreader? I keep seeing your
> posts as replies only to the top post.
>
> --
> Simen
Actually I'm getting his messages as emails, and just thought he was only
sending to me.
Am 20.07.2010 19:15, schrieb Jesse Phillips:
Simen kjaeraas Wrote:
Rory McGuire wrote:
[snip]
Rory, is there something wrong with your newsreader? I keep seeing your
posts as replies only to the top post.
--
Simen
Actually I'm getting his messages as emails, and just thought he was only
On Tue, 20 Jul 2010 11:02:57 -0400, Sean Kelly
wrote:
Steven Schveighoffer Wrote:
How do we make this work?
auto str = "hello world";
foreach(c; str)
assert(is(typeof(c) == dchar));
foreach (dchar c; str)
assert(...);
This feature has been in D for years.
The omission of dchar
On Tuesday, July 20, 2010 05:30:51 DCoder wrote:
> I'm wondering how bad would it be introduce a schar (short char, 1
> byte) type and then let char simply map to a "default" char type:
> dchar, wchar, or whatever we tell the compiler. By default, char
> would map to dchar.
>
> alias char dchar;
>
Andrei Alexandrescu wrote:
I think otherwise. In fact I confess I am extremely excited. The current
state of affairs described built-in strings very accurately: they are
formally bidirectional ranges, yet they offer random access for code
units that you can freely use if you so wish. It's model
bearophile wrote:
Probably too late to change that one.
There is very little D2 code around, so little changes as this one are possible
still.
It's a D1 feature, and has been there since nearly the beginning.
Michel Fortin wrote:
As for the "too late to change" stance, I'm not sure. It'll certainly be
to late to change in a year, but right now D2 is still pretty new. What
makes you say it's too late?
As I said to bearophile, it's a D1 feature.
On Tue, 20 Jul 2010 18:35:12 +0200, Simen kjaeraas
wrote:
Rory McGuire wrote:
[snip]
Rory, is there something wrong with your newsreader? I keep seeing your
posts as replies only to the top post.
I'm using opera mail. Any suggestions for Linux+Windows, excluding
thunderbird(slow)?
On Tue, 20 Jul 2010 14:29:43 -0400, Walter Bright
wrote:
bearophile wrote:
Probably too late to change that one.
There is very little D2 code around, so little changes as this one are
possible still.
It's a D1 feature, and has been there since nearly the beginning.
Since when did we c
Sean Kelly wrote:
I've had the same experience. The proposed changes would make string useless
to me, even for Unicode work. I'd end up using ubyte[] instead.
At this point, the experience with D strings is that D gets it right. To change
it would require someone who has spent a *lot* of hou
Jérôme M. Berger wrote:
And what about this one:
void func(T) (T range) {
foreach (elem; range)
assert (is (typeof (elem) == ElementType!(T)));
}
func ("azerty");
auto a = [ 1, 2, 3, 4, 5];
func (a);
You can specialize the template for strings:
void func(T:string)(T range
Steven Schveighoffer wrote:
The omission of dchar is on purpose. Phobos has characterized string as
a bidirectional range of dchars. For every range where I do:
foreach(e; range)
e is of the type of the range. Except for char and wchar. This
schizophrenia of type induction is very bad for
On Tue, 20 Jul 2010 15:21:34 -0400, Walter Bright
wrote:
Steven Schveighoffer wrote:
The omission of dchar is on purpose. Phobos has characterized string
as a bidirectional range of dchars. For every range where I do:
foreach(e; range)
e is of the type of the range. Except for char an
Walter Bright wrote:
> Jérôme M. Berger wrote:
>> And what about this one:
>>
>> void func(T) (T range) {
>> foreach (elem; range)
>> assert (is (typeof (elem) == ElementType!(T)));
>> }
>>
>> func ("azerty");
>> auto a = [ 1, 2, 3, 4, 5];
>> func (a);
>
> You can specialize the te
Jesse Phillips wrote:
> Simen kjaeraas Wrote:
>
>> Rory McGuire wrote:
>>
>> [snip]
>>
>> Rory, is there something wrong with your newsreader? I keep seeing your
>> posts as replies only to the top post.
>>
>> --
>> Simen
>
> Actually I'm getting his messages as emails, and just thought he was
Steven Schveighoffer wrote:
On Tue, 20 Jul 2010 14:29:43 -0400, Walter Bright
wrote:
It's a D1 feature, and has been there since nearly the beginning.
Since when did we care about D1 compatibility?
We care about incompatibilities that silently break code.
const, inout, array appending, fi
Steven Schveighoffer wrote:
On Tue, 20 Jul 2010 15:21:34 -0400, Walter Bright
wrote:
Steven Schveighoffer wrote:
The omission of dchar is on purpose. Phobos has characterized string
as a bidirectional range of dchars. For every range where I do:
foreach(e; range)
e is of the type of the
Jérôme M. Berger wrote:
Walter Bright wrote:
You can specialize the template for strings:
void func(T:string)(T range) { ... }
Sure, i can also not use a template and write however many
overloaded functions I need. So what are templates for?
The overloaded template specialization ca
Rory McGuire wrote:
I'm using opera mail. Any suggestions for Linux+Windows, excluding
thunderbird(slow)?
I use thunderbird on both windows & linux, haven't noticed speed problems other
than my slow internet connection.
I have noticed that thunderbird uses multithreading fairly effectively t
Walter Bright wrote:
Steven Schveighoffer wrote:
On Tue, 20 Jul 2010 14:29:43 -0400, Walter Bright
wrote:
It's a D1 feature, and has been there since nearly the beginning.
Since when did we care about D1 compatibility?
We care about incompatibilities that silently break code.
const, inou
Walter Bright wrote:
Steven Schveighoffer wrote:
On Tue, 20 Jul 2010 15:21:34 -0400, Walter Bright
wrote:
Steven Schveighoffer wrote:
The omission of dchar is on purpose. Phobos has characterized
string as a bidirectional range of dchars. For every range where I do:
foreach(e; range)
e
On Tuesday, July 20, 2010 11:45:41 Rory McGuire wrote:
> On Tue, 20 Jul 2010 18:35:12 +0200, Simen kjaeraas
>
> wrote:
> > Rory McGuire wrote:
> >
> > [snip]
> >
> > Rory, is there something wrong with your newsreader? I keep seeing your
> > posts as replies only to the top post.
>
> I'm usin
I did not read all the discussion in detail, but in my opinion
something that would be very useful in a library is
struct String{
void *ptr;
size_t _l;
enum :size_t {
MaskLen=((~cast(size_t)0)>>2)
}
enum :int {
BitsLen=8*si
"Walter Bright" ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ × ÎÏ×ÏÓÔÑÈ
ÓÌÅÄÕÀÝÅÅ: news:i24st1$12u...@digitalmars.com...
> Jerome M. Berger wrote:
>> And what about this one:
>>
>> void func(T) (T range) {
>> foreach (elem; range)
>> assert (is (typeof (elem) == ElementType!(T)));
>> }
>>
>> func ("azerty");
>>
On 20/07/2010 20:41, "Jérôme M. Berger" wrote:
Jesse Phillips wrote:
Simen kjaeraas Wrote:
Funny
thing is I don't have any problem with his messages but yours does
appear as a reply to the top post...
Jerome
In my client (Thunderbird 3), it appears as a top level post. Its b
51 matches
Mail list logo
