On Tue, May 31, 2016 at 10:47:56PM +0300, Dmitry Olshansky via Digitalmars-d
wrote:
> On 31-May-2016 01:00, Walter Bright wrote:
> > On 5/30/2016 11:25 AM, Adam D. Ruppe wrote:
> > > I don't agree on changing those. Indexing and slicing a char[] is
> > > really useful and actually not hard to do c
On Tuesday, 31 May 2016 at 20:20:46 UTC, Marco Leise wrote:
Am Tue, 31 May 2016 16:29:33 +
schrieb Joakim :
Part of it is the complexity of written language, part of it
is bad technical decisions. Building the default string type
in D around the horrible UTF-8 encoding was a fundamental
On Tue, May 31, 2016 at 10:38:03PM +0200, Timon Gehr via Digitalmars-d wrote:
> On 31.05.2016 21:51, Steven Schveighoffer wrote:
> > On 5/31/16 3:32 PM, H. S. Teoh via Digitalmars-d wrote:
> > > On Tue, May 31, 2016 at 02:30:08PM -0400, Andrei Alexandrescu via
> > > Digitalmars-d wrote:
> > > [...]
On Tuesday, 31 May 2016 at 20:28:32 UTC, ag0aep6g wrote:
On 05/31/2016 06:29 PM, Joakim wrote:
D devs should lead the way in getting rid of the UTF-8
encoding, not
bickering about how to make it more palatable. I suggested a
single-byte encoding for most languages, with double-byte for
the on
On 05/31/2016 03:32 PM, H. S. Teoh via Digitalmars-d wrote:
Let's put the question this way. Given the following string, what do
*you* think walkLength should return?
şŭt̥ḛ́k̠
The number of code units in the string. That's the contract promised and
honored by Phobos. -- Andrei
On 05/31/2016 04:55 PM, Andrei Alexandrescu wrote:
On 05/31/2016 03:32 PM, H. S. Teoh via Digitalmars-d wrote:
Let's put the question this way. Given the following string, what do
*you* think walkLength should return?
şŭt̥ḛ́k̠
The number of code units in the string. That's the contrac
On 05/31/2016 03:34 PM, ag0aep6g wrote:
On 05/31/2016 07:21 PM, Andrei Alexandrescu wrote:
Could you please substantiate that? My understanding is that code unit
is a higher-level Unicode notion independent of encoding, whereas code
point is an encoding-dependent representation detail. -- Andrei
On 05/31/2016 03:44 PM, Jonathan M Davis via Digitalmars-d wrote:
In the vast majority of cases what folks care about is full character
How are you so sure? -- Andrei
On 05/31/2016 04:01 PM, Jonathan M Davis via Digitalmars-d wrote:
Wasn't the whole point of operating at the code point level by default to
make it so that code would be operating on full characters by default
instead of chopping them up as is so easy to do when operating at the code
unit level?
On 31.05.2016 22:20, Marco Leise wrote:
Am Tue, 31 May 2016 16:29:33 +
schrieb Joakim:
>Part of it is the complexity of written language, part of it is
>bad technical decisions. Building the default string type in D
>around the horrible UTF-8 encoding was a fundamental mistake,
>both in te
Am Tue, 31 May 2016 13:06:16 -0400
schrieb Andrei Alexandrescu :
> On 05/31/2016 12:54 PM, Jonathan M Davis via Digitalmars-d wrote:
> > Equality does not require decoding. Similarly, functions like find don't
> > either. Something like filter generally would, but it's also not
> > particularly no
On Tue, May 31, 2016 at 05:01:17PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 05/31/2016 04:01 PM, Jonathan M Davis via Digitalmars-d wrote:
> > Wasn't the whole point of operating at the code point level by
> > default to make it so that code would be operating on full
> > character
On Tuesday, 31 May 2016 at 21:01:17 UTC, Andrei Alexandrescu
wrote:
If user code needs to go upper at the grapheme level, they can
If anything this thread strengthens my opinion that
autodecoding is a sweet spot. -- Andrei
Unicode FAQ disagrees (http://unicode.org/faq/utf_bom.html):
"Q: How
Am Tue, 31 May 2016 16:56:43 -0400
schrieb Andrei Alexandrescu :
> On 05/31/2016 03:44 PM, Jonathan M Davis via Digitalmars-d wrote:
> > In the vast majority of cases what folks care about is full character
>
> How are you so sure? -- Andrei
Because a full character is the typical unit of a wr
On 5/31/2016 1:20 PM, Marco Leise wrote:
[...]
I agree. I dealt the madness of code pages, Shift-JIS, EBCDIC, locales, etc., in
the pre-Unicode days. Despite its problems, Unicode (and UTF-8) is a major
improvement, and I mean major.
16 years ago, I bet that Unicode was the future, and even
On 06/01/2016 12:47 AM, Walter Bright wrote:
But I didn't know which encoding would win - UTF-8, UTF-16, or UCS-2, so
D bet on all three. If I had a do-over, I'd just support UTF-8. UTF-16
is useful pretty much only as a transitional encoding to talk with
Windows APIs. Nobody uses UCS-2 (it consu
On 5/31/2016 1:57 AM, Chris wrote:
1. Given you experience with Warp, how hard would it be to clean Phobos up?
It's not hard, it's just a bit tedious.
2. After recoding a number of Phobos functions, how much code did actually break
(yours or someone else's)?.
It's been a while so I don't re
On 05/31/2016 04:55 PM, Andrei Alexandrescu wrote:
On 05/31/2016 04:55 PM, Andrei Alexandrescu wrote:
On 05/31/2016 03:32 PM, H. S. Teoh via Digitalmars-d wrote:
Let's put the question this way. Given the following string, what do
*you* think walkLength should return?
şŭt̥ḛ́k̠
The nu
On 05/31/2016 01:23 PM, Andrei Alexandrescu wrote:
On 05/31/2016 01:15 PM, Jonathan M Davis via Digitalmars-d wrote:
The standard library has to fight against itself because of autodecoding!
The vast majority of the algorithms in Phobos are special-cased on
strings
in an attempt to get around au
On 5/31/16 4:38 PM, Timon Gehr wrote:
On 31.05.2016 21:51, Steven Schveighoffer wrote:
On 5/31/16 3:32 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, May 31, 2016 at 02:30:08PM -0400, Andrei Alexandrescu via
Digitalmars-d wrote:
[...]
Does walkLength yield the same number for all representati
On Tuesday, May 31, 2016 20:38:14 Nick Sabalausky via Digitalmars-d wrote:
> On 05/31/2016 04:55 PM, Andrei Alexandrescu wrote:
> > On 05/31/2016 04:55 PM, Andrei Alexandrescu wrote:
> >> On 05/31/2016 03:32 PM, H. S. Teoh via Digitalmars-d wrote:
> >>> Let's put the question this way. Given the fo
On Tuesday, May 31, 2016 23:36:20 Marco Leise via Digitalmars-d wrote:
> Am Tue, 31 May 2016 16:56:43 -0400
>
> schrieb Andrei Alexandrescu :
> > On 05/31/2016 03:44 PM, Jonathan M Davis via Digitalmars-d wrote:
> > > In the vast majority of cases what folks care about is full character
> >
> > How
On Wednesday, 1 June 2016 at 02:17:21 UTC, Jonathan M Davis wrote:
...
This thread is going in circles; the against crowd has stated
each of their arguments very clearly at least five times in
different ways.
The cost/benefit problems with auto decoding are as clear as day.
If the evidence
On 5/31/2016 4:00 PM, ag0aep6g wrote:
Wikipedia says [1] that UCS-2 is essentially UTF-16 without surrogate pairs. I
suppose you mean UTF-32/UCS-4.
[1] https://en.wikipedia.org/wiki/UTF-16
Thanks for the correction.
On Tuesday, 31 May 2016 at 16:29:33 UTC, Joakim wrote:
UTF-8 is an antiquated hack that needs to be eradicated. It
forces all other languages than English to be twice as long,
for no good reason, have fun with that when you're downloading
text on a 2G connection in the developing world.
I as
On Tuesday, 31 May 2016 at 20:56:43 UTC, Andrei Alexandrescu
wrote:
On 05/31/2016 03:44 PM, Jonathan M Davis via Digitalmars-d
wrote:
In the vast majority of cases what folks care about is full
character
How are you so sure? -- Andrei
He doesn't need to be sure. You are the one advocating fo
On Tuesday, 31 May 2016 at 21:01:17 UTC, Andrei Alexandrescu
wrote:
On 05/31/2016 04:01 PM, Jonathan M Davis via Digitalmars-d
wrote:
Wasn't the whole point of operating at the code point level by
default to
make it so that code would be operating on full characters by
default
instead of choppi
On Wednesday, 1 June 2016 at 01:13:17 UTC, Steven Schveighoffer
wrote:
On 5/31/16 4:38 PM, Timon Gehr wrote:
What about e.g. joiner?
Compiler error. Better than what it does now.
I believe everything that does only concatenation will work
correctly. That's why joiner() is one of those algor
On Wednesday, 1 June 2016 at 10:04:42 UTC, Marc Schütz wrote:
On Tuesday, 31 May 2016 at 16:29:33 UTC, Joakim wrote:
UTF-8 is an antiquated hack that needs to be eradicated. It
forces all other languages than English to be twice as long,
for no good reason, have fun with that when you're downl
On 06/01/2016 06:25 AM, Marc Schütz wrote:
On Tuesday, 31 May 2016 at 21:01:17 UTC, Andrei Alexandrescu wrote:
On 05/31/2016 04:01 PM, Jonathan M Davis via Digitalmars-d wrote:
Wasn't the whole point of operating at the code point level by
default to
make it so that code would be operating on f
On 06/01/2016 10:29 AM, Andrei Alexandrescu wrote:
On 06/01/2016 06:25 AM, Marc Schütz wrote:
On Tuesday, 31 May 2016 at 21:01:17 UTC, Andrei Alexandrescu wrote:
The point is to operate on representation-independent entities
(Unicode code points) instead of low-level representation-specific
ar
On 06/01/2016 12:41 PM, Nick Sabalausky wrote:
As has been explained countless times already, code points are a non-1:1
internal representation of graphemes. Code points don't exist for their
own sake, their entire existence is purely as a way to encode graphemes.
Of course, thank you.
Whethe
On Tuesday, 31 May 2016 at 19:33:03 UTC, Andrei Alexandrescu
wrote:
On 05/31/2016 02:46 PM, Timon Gehr wrote:
On 31.05.2016 20:30, Andrei Alexandrescu wrote:
D's
Phobos'
foreach, too. -- Andrei
Incorrect. https://dpaste.dzfl.pl/ba7a65d59534
On 06/01/2016 01:35 PM, ZombineDev wrote:
On Tuesday, 31 May 2016 at 19:33:03 UTC, Andrei Alexandrescu wrote:
On 05/31/2016 02:46 PM, Timon Gehr wrote:
On 31.05.2016 20:30, Andrei Alexandrescu wrote:
D's
Phobos'
foreach, too. -- Andrei
Incorrect. https://dpaste.dzfl.pl/ba7a65d59534
Try
On Wednesday, 1 June 2016 at 17:57:15 UTC, Andrei Alexandrescu
wrote:
Try typing the iteration variable with "dchar". -- Andrei
Or you can type it as wchar...
But important to note: that's opt in, not automatic.
On Wednesday, 1 June 2016 at 17:57:15 UTC, Andrei Alexandrescu
wrote:
On 06/01/2016 01:35 PM, ZombineDev wrote:
On Tuesday, 31 May 2016 at 19:33:03 UTC, Andrei Alexandrescu
wrote:
On 05/31/2016 02:46 PM, Timon Gehr wrote:
On 31.05.2016 20:30, Andrei Alexandrescu wrote:
D's
Phobos'
foreach
On Wednesday, 1 June 2016 at 19:07:26 UTC, ZombineDev wrote:
On Wednesday, 1 June 2016 at 17:57:15 UTC, Andrei Alexandrescu
wrote:
On 06/01/2016 01:35 PM, ZombineDev wrote:
On Tuesday, 31 May 2016 at 19:33:03 UTC, Andrei Alexandrescu
wrote:
On 05/31/2016 02:46 PM, Timon Gehr wrote:
On 31.05.2
On 06/01/2016 03:07 PM, ZombineDev wrote:
This is not autodecoding. There is nothing auto-magic w.r.t. strings in
plain foreach.
I understand where you're coming from, but it actually is autodecoding.
Consider:
byte[] a;
foreach (byte x; a) {}
foreach (short x; a) {}
foreach (int x; a) {}
T
On Wednesday, 1 June 2016 at 19:52:01 UTC, Andrei Alexandrescu
wrote:
foreach (dchar x; a) {}
The latter two do autodecoding, not coversion as the rest of
the language.
This seems to be a miscommunication with semantics. This is not
auto-decoding at all; you're decoding, but there is nothing
On 06/01/2016 05:30 PM, Jack Stouffer wrote:
On Wednesday, 1 June 2016 at 19:52:01 UTC, Andrei Alexandrescu wrote:
foreach (dchar x; a) {}
The latter two do autodecoding, not coversion as the rest of the
language.
This seems to be a miscommunication with semantics. This is not
auto-decoding at
On Wednesday, 1 June 2016 at 19:52:01 UTC, Andrei Alexandrescu
wrote:
On 06/01/2016 03:07 PM, ZombineDev wrote:
This is not autodecoding. There is nothing auto-magic w.r.t.
strings in
plain foreach.
I understand where you're coming from, but it actually is
autodecoding. Consider:
byte[] a;
On 06/01/2016 06:09 PM, ZombineDev wrote:
Regardless of how different people may call it, it's not what this
thread is about.
Yes, definitely - but then again we can't after each invalidated claim
to go "yeah well but that other point stands".
Deprecating front, popFront and empty for narro
On Wednesday, 1 June 2016 at 22:24:49 UTC, Andrei Alexandrescu
wrote:
Deprecating front, popFront and empty for narrow
strings is what we are talking about here.
That will not happen. Walter and I consider the cost excessive
and the benefit too small.
This has little to do with
explicit str
On Wednesday, 1 June 2016 at 19:52:01 UTC, Andrei Alexandrescu
wrote:
On 06/01/2016 03:07 PM, ZombineDev wrote:
This is not autodecoding. There is nothing auto-magic w.r.t.
strings in
plain foreach.
I understand where you're coming from, but it actually is
autodecoding. Consider:
byte[] a;
On Wednesday, 1 June 2016 at 22:24:49 UTC, Andrei Alexandrescu
wrote:
On 06/01/2016 06:09 PM, ZombineDev wrote:
Regardless of how different people may call it, it's not what
this
thread is about.
Yes, definitely - but then again we can't after each
invalidated claim to go "yeah well but that
On Wednesday, 1 June 2016 at 14:29:58 UTC, Andrei Alexandrescu
wrote:
On 06/01/2016 06:25 AM, Marc Schütz wrote:
On Tuesday, 31 May 2016 at 21:01:17 UTC, Andrei Alexandrescu
wrote:
The point is to operate on representation-independent entities
(Unicode code points) instead of low-level
represe
...
B) This strange feature you need to know about is here because
we chose comparability with old code, over building the best
language possible. The language managed to continue growing
(but not as fast as we hoped) only because of the other good
features. You should use this feature and he
On 6/1/16 6:24 PM, Andrei Alexandrescu wrote:
On 06/01/2016 06:09 PM, ZombineDev wrote:
Deprecating front, popFront and empty for narrow
strings is what we are talking about here.
That will not happen. Walter and I consider the cost excessive and the
benefit too small.
If this doesn't happ
over matters that are simply missing the point.
This is what's happening here. We worked ourselves to a foam because the
creator of the language started a thread entitled "The Case Against
Autodecode", whilst fully understanding there is no way to actually
eliminate autodecode. Th
On 06/02/2016 09:05 AM, Steven Schveighoffer wrote:
On 6/1/16 6:24 PM, Andrei Alexandrescu wrote:
On 06/01/2016 06:09 PM, ZombineDev wrote:
Deprecating front, popFront and empty for narrow
strings is what we are talking about here.
That will not happen. Walter and I consider the cost excess
On 6/1/16 6:31 AM, Marc Schütz wrote:
On Wednesday, 1 June 2016 at 01:13:17 UTC, Steven Schveighoffer wrote:
On 5/31/16 4:38 PM, Timon Gehr wrote:
What about e.g. joiner?
Compiler error. Better than what it does now.
I believe everything that does only concatenation will work correctly.
Tha
On 01.06.2016 23:48, Andrei Alexandrescu wrote:
On 06/01/2016 05:30 PM, Jack Stouffer wrote:
On Wednesday, 1 June 2016 at 19:52:01 UTC, Andrei Alexandrescu wrote:
foreach (dchar x; a) {}
The latter two do autodecoding, not coversion as the rest of the
language.
This seems to be a miscommunica
On 6/2/16 9:09 AM, Andrei Alexandrescu wrote:
On 06/02/2016 09:05 AM, Steven Schveighoffer wrote:
On 6/1/16 6:24 PM, Andrei Alexandrescu wrote:
On 06/01/2016 06:09 PM, ZombineDev wrote:
Deprecating front, popFront and empty for narrow
strings is what we are talking about here.
That will no
On 02.06.2016 15:06, Andrei Alexandrescu wrote:
On 06/02/2016 06:42 AM, ZombineDev wrote:
On Wednesday, 1 June 2016 at 22:24:49 UTC, Andrei Alexandrescu wrote:
On 06/01/2016 06:09 PM, ZombineDev wrote:
Regardless of how different people may call it, it's not what this
thread is about.
Yes, d
On 06/02/2016 09:25 AM, Steven Schveighoffer wrote:
And yes, I'm about to kill this thread from my newsreader, since it's
wasting too much of my time...
A good idea for all of us. Could you also please look on my post on our
meetup page? Thx! -- Andrei
On 02.06.2016 15:09, Andrei Alexandrescu wrote:
You can change string literals to be something other than arrays, and
then we have a path forward. But as long as char[] is not an array, we
have lost the battle of sanity.
Yeah, it's a miracle the language stays glued eh.
...
It's not a langu
On Thursday, 2 June 2016 at 13:11:10 UTC, Steven Schveighoffer
wrote:
On 6/1/16 6:31 AM, Marc Schütz wrote:
I believe everything that does only concatenation will work
correctly.
That's why joiner() is one of those algorithms that should
accept
strings directly without going through any decodin
od can alienate itself from the needs of
the larger community and get into a frenzy over matters that
are simply missing the point.
This is what's happening here. We worked ourselves to a foam
because the creator of the language started a thread entitled
"The Case Against Autodecode&qu
On Thursday, 2 June 2016 at 13:06:44 UTC, Andrei Alexandrescu
wrote:
Look at reddit and hackernews, too - admittedly other
self-selected communities. Language debates often spring about.
How often is the point being made that D is wanting because of
its string support? Nada.
I've been lurki
On Thursday, 2 June 2016 at 13:55:28 UTC, cym13 wrote:
If you are to stay with autodecoding (and I hope you won't) then
please, *please*, at least make it decode to graphemes so that
it decodes to something that actually have some kind of meaning
of its own.
That would cause just as much - if n
On 06/02/2016 09:55 AM, cym13 wrote:
On Thursday, 2 June 2016 at 13:06:44 UTC, Andrei Alexandrescu wrote:
Your claim was obliterated, and now you continue arguing it by
adjusting term definitions on the fly, while at the same time
awesomely claiming to choose the high road by not wasting time to
On Thursday, 2 June 2016 at 13:06:44 UTC, Andrei Alexandrescu
wrote:
This is what's happening here. We worked ourselves to a foam
because the creator of the language started a thread entitled
"The Case Against Autodecode", whilst fully understanding there
is no way to act
the point.
Appeal to authority.
> This is what's happening here. We worked ourselves to a foam because
> the creator of the language started a thread entitled "The Case
> Against Autodecode", whilst fully understanding there is no way to
> actually eliminate autodecode.
I
On 06/02/2016 10:14 AM, jmh530 wrote:
However, the case against autodecoding is clearly popular. At a minimum,
it has resulted in a significant amount of time dedicated to forum
discussion and has made you metaphorically angry at Walter. Resources
spent grumbling about it could be better spent el
On Thursday, 2 June 2016 at 13:11:10 UTC, Steven Schveighoffer
wrote:
This means that a string is a range. What is it a range of? If
you want to make it a range of code units, I think you will
lose that battle.
After the first migration step joiner will return a decoded dchar
range just like
On 06/02/2016 10:53 AM, Kagamin wrote:
On Thursday, 2 June 2016 at 13:06:44 UTC, Andrei Alexandrescu wrote:
This is what's happening here. We worked ourselves to a foam because
the creator of the language started a thread entitled "The Case
Against Autodecode", whilst fully unde
s that are simply missing the point.
Appeal to authority.
You cut the context, which was rampant speculation.
This is what's happening here. We worked ourselves to a foam because
the creator of the language started a thread entitled "The Case
Against Autodecode", whilst fully unde
On Thursday, 2 June 2016 at 15:02:13 UTC, Andrei Alexandrescu
wrote:
Yah, this is a bummer and one of the larger issues of our
community: there's too much talking about doing things and too
little doing things.
We wrote a PR to implement the first step in the autodecode
deprecation cycle. Gra
On Thursday, 2 June 2016 at 15:38:46 UTC, Adam D. Ruppe wrote:
On Thursday, 2 June 2016 at 15:02:13 UTC, Andrei Alexandrescu
wrote:
Yah, this is a bummer and one of the larger issues of our
community: there's too much talking about doing things and too
little doing things.
We wrote a PR to im
On Thursday, June 02, 2016 09:06:44 Andrei Alexandrescu via Digitalmars-d
wrote:
> Meanwhile, I go to conferences. Train and consult at large companies.
> Dozens every year, cumulatively thousands of people. I talk about D and
> ask people what it would take for them to use the language. Invariabl
On Thursday, 2 June 2016 at 15:38:46 UTC, Adam D. Ruppe wrote:
We wrote a PR to implement the first step in the autodecode
deprecation cycle.
It outright deprecated popFront - that's not the first step in
the migration.
On Thursday, 2 June 2016 at 15:50:54 UTC, Kagamin wrote:
It outright deprecated popFront - that's not the first step in
the migration.
Which gave us the list of places inside Phobos to fix, only about
two hours of work, and proved that the version() method was
viable (and REALLY easy to imple
On 06/02/2016 11:38 AM, Adam D. Ruppe wrote:
On Thursday, 2 June 2016 at 15:02:13 UTC, Andrei Alexandrescu wrote:
Yah, this is a bummer and one of the larger issues of our
community: there's too much talking about doing things and too
little doing things.
We wrote a PR to implement the first s
On Thursday, 2 June 2016 at 15:06:20 UTC, Andrei Alexandrescu
wrote:
Autodecode doesn't need to be removed from phobos completely,
it only
needs to be more bearable, like it is in the foreach
statement. E.g.
byDchar will stay, initial idea is to actually put it to more
intensive
usage in phobo
On 06/02/2016 11:58 AM, Jonathan M Davis via Digitalmars-d wrote:
On Thursday, June 02, 2016 09:06:44 Andrei Alexandrescu via Digitalmars-d
wrote:
Meanwhile, I go to conferences. Train and consult at large companies.
Dozens every year, cumulatively thousands of people. I talk about D and
ask peo
On 06/02/2016 12:14 PM, Kagamin wrote:
On Thursday, 2 June 2016 at 15:06:20 UTC, Andrei Alexandrescu wrote:
Autodecode doesn't need to be removed from phobos completely, it only
needs to be more bearable, like it is in the foreach statement. E.g.
byDchar will stay, initial idea is to actually pu
On Thursday, 2 June 2016 at 16:02:18 UTC, Adam D. Ruppe wrote:
Which gave us the list of places inside Phobos to fix, only
about two hours of work, and proved that the version() method
was viable (and REALLY easy to implement).
Yes, it was a research PR that was never meant to be an
implement
On 06/02/2016 12:45 PM, Kagamin wrote:
On Thursday, 2 June 2016 at 16:02:18 UTC, Adam D. Ruppe wrote:
Which gave us the list of places inside Phobos to fix, only about two
hours of work, and proved that the version() method was viable (and
REALLY easy to implement).
Yes, it was a research PR t
On Thursday, 2 June 2016 at 14:28:44 UTC, Andrei Alexandrescu
wrote:
That's not going to work. A false impression created in this
thread has been that code points are useless
They _are_ useless for almost anything you can do with strings.
The only places where they should be used are std.uni a
On Thursday, 2 June 2016 at 16:12:01 UTC, Andrei Alexandrescu
wrote:
Would you realistically have advised me to merge it?
Not at this time, no, but I also wouldn't advise you to close it
and tell us to stop trying if you were actually open to a chance.
You closed that and posted this at abou
On 06/02/2016 02:36 PM, Adam D. Ruppe wrote:
We had a migration plan and enough excitement to start working on the code
I don't think the plan is realistic. How can I tell you this without you
getting mad at me? Apparently the only way to go is do as you say. -- Andrei
On 02.06.2016 15:48, Marc Schütz wrote:
No, I don't want to make string a range of anything, I want to provide
an additional overload for joiner() that accepts a const(char)[], and
returns a range of chars.
If strings are not ranges, returning a range of chars is inconsistent.
On Thursday, 2 June 2016 at 16:21:33 UTC, Andrei Alexandrescu
wrote:
On 06/02/2016 12:14 PM, Kagamin wrote:
On Thursday, 2 June 2016 at 15:06:20 UTC, Andrei Alexandrescu
wrote:
Autodecode doesn't need to be removed from phobos
completely, it only
needs to be more bearable, like it is in the for
On 06/02/2016 01:54 PM, Marc Schütz wrote:
On Thursday, 2 June 2016 at 14:28:44 UTC, Andrei Alexandrescu wrote:
That's not going to work. A false impression created in this thread
has been that code points are useless
They _are_ useless for almost anything you can do with strings. The only
pla
On Thursday, 2 June 2016 at 18:43:54 UTC, Andrei Alexandrescu
wrote:
I don't think the plan is realistic. How can I tell you this
without you getting mad at me?
You get out of the way and let the community get to work.
Actually delegate, let people take ownership of problems, success
and fail
On 06/02/2016 09:05 PM, Andrei Alexandrescu wrote:
Pretty much everything. Consider s and s1 string variables with possibly
different encodings (UTF8/UTF16).
* s.all!(c => c == 'ö') works only with autodecoding. It returns always
false without.
Doesn't work with autodecoding (to code points) w
ag0aep6g wrote:
> On 06/02/2016 09:05 PM, Andrei Alexandrescu wrote:
>> Pretty much everything. Consider s and s1 string variables with possibly
>> different encodings (UTF8/UTF16).
>>
>> * s.all!(c => c == 'ö') works only with autodecoding. It returns always
>> false without.
>
> Doesn't work w
On Thursday, 2 June 2016 at 19:05:44 UTC, Andrei Alexandrescu
wrote:
Pretty much everything. Consider s and s1 string variables with
possibly different encodings (UTF8/UTF16).
...
Your 'ö' examples will NOT work reliably with auto-decoded code
points, and for nearly the same reason that they
On Thursday, 2 June 2016 at 19:05:44 UTC, Andrei Alexandrescu
wrote:
Pretty much everything. Consider s and s1 string variables with
possibly different encodings (UTF8/UTF16).
* s.all!(c => c == 'ö') works only with autodecoding. It
returns always false without.
False. Many characters can
On 02.06.2016 21:26, Andrei Alexandrescu wrote:
ag0aep6g wrote:
On 06/02/2016 09:05 PM, Andrei Alexandrescu wrote:
Pretty much everything. Consider s and s1 string variables with possibly
different encodings (UTF8/UTF16).
* s.all!(c => c == 'ö') works only with autodecoding. It returns always
On 06/02/2016 09:26 PM, Andrei Alexandrescu wrote:
ag0aep6g wrote:
On 06/02/2016 09:05 PM, Andrei Alexandrescu wrote:
Pretty much everything. Consider s and s1 string variables with possibly
different encodings (UTF8/UTF16).
* s.all!(c => c == 'ö') works only with autodecoding. It returns alw
On 02.06.2016 21:05, Andrei Alexandrescu wrote:
On 06/02/2016 01:54 PM, Marc Schütz wrote:
On Thursday, 2 June 2016 at 14:28:44 UTC, Andrei Alexandrescu wrote:
That's not going to work. A false impression created in this thread
has been that code points are useless
They _are_ useless for almo
On 6/2/2016 12:05 PM, Andrei Alexandrescu wrote:
* s.all!(c => c == 'ö') works only with autodecoding. It returns always false
without.
The o is inferred as a wchar. The lamda then is inferred to return a wchar. The
algorithm can check that the input is char[], and is being tested against a
w
On 06/02/2016 03:13 PM, Adam D. Ruppe wrote:
On Thursday, 2 June 2016 at 18:43:54 UTC, Andrei Alexandrescu wrote:
I don't think the plan is realistic. How can I tell you this without
you getting mad at me?
You get out of the way and let the community get to work. Actually
delegate, let people
On 02.06.2016 22:07, Walter Bright wrote:
On 6/2/2016 12:05 PM, Andrei Alexandrescu wrote:
* s.all!(c => c == 'ö') works only with autodecoding. It returns
always false
without.
The o is inferred as a wchar. The lamda then is inferred to return a
wchar.
No, the lambda returns a bool.
The a
On 06/02/2016 03:34 PM, deadalnix wrote:
On Thursday, 2 June 2016 at 19:05:44 UTC, Andrei Alexandrescu wrote:
Pretty much everything. Consider s and s1 string variables with
possibly different encodings (UTF8/UTF16).
* s.all!(c => c == 'ö') works only with autodecoding. It returns
always false
On 06/02/2016 03:34 PM, tsbockman wrote:
On Thursday, 2 June 2016 at 19:05:44 UTC, Andrei Alexandrescu wrote:
Pretty much everything. Consider s and s1 string variables with
possibly different encodings (UTF8/UTF16).
...
Your 'ö' examples will NOT work reliably with auto-decoded code points,
a
On 02.06.2016 22:13, Andrei Alexandrescu wrote:
On 06/02/2016 03:34 PM, deadalnix wrote:
On Thursday, 2 June 2016 at 19:05:44 UTC, Andrei Alexandrescu wrote:
Pretty much everything. Consider s and s1 string variables with
possibly different encodings (UTF8/UTF16).
* s.all!(c => c == 'ö') works
On Thursday, 2 June 2016 at 20:13:14 UTC, Andrei Alexandrescu
wrote:
On 06/02/2016 03:34 PM, tsbockman wrote:
[...]
They do work per spec: find this code point. It would be
surprising if 'ö' were found but the string were positioned at
a different code point.
[...]
Well there's gotta be
On Thursday, 2 June 2016 at 20:13:52 UTC, Andrei Alexandrescu
wrote:
On 06/02/2016 03:34 PM, deadalnix wrote:
On Thursday, 2 June 2016 at 19:05:44 UTC, Andrei Alexandrescu
wrote:
Pretty much everything. Consider s and s1 string variables
with
possibly different encodings (UTF8/UTF16).
* s.all
201 - 300 of 441 matches
Mail list logo
