Re: The Case Against Autodecode

On 5/13/2016 2:12 AM, Chris wrote: If autodecode is killed, could we have a test version asap? I'd be willing to test my programs with autodecode turned off and see what happens. Others should do likewise and we could come up with a transition strategy based on what happened. You can avoid

Re: The Case Against Autodecode

On Friday, 13 May 2016 at 10:38:09 UTC, Jonathan M Davis wrote: IIRC, Andrei talked in TDPL about how Java's choice to go with UTF-16 was worse than the choice to go with UTF-8, because it was correct in many more cases UTF-16 was a migration from UCS-2, and UCS-2 was superior at the time.

Re: The Case Against Autodecode

On Friday, 13 May 2016 at 00:47:04 UTC, Jack Stouffer wrote: If you're serious about removing auto-decoding, which I think you and others have shown has merits, you have to the THE SIMPLEST migration path ever, or you will kill D. I'm talking a simple press of a button. char[] is always

Re: The Case Against Autodecode

On Friday, 13 May 2016 at 10:38:09 UTC, Jonathan M Davis wrote: Ideally, algorithms would be Unicode aware as appropriate, but the default would be to operate on code units with wrappers to handle decoding by code point or grapheme. Then it's easy to write fast code while still allowing for

Re: The Case Against Autodecode

On Thursday, 12 May 2016 at 23:16:23 UTC, H. S. Teoh wrote: Therefore, autodecoding actually only produces intuitively correct results when your string has a 1-to-1 correspondence between grapheme and code point. In general, this is only true for a small subset of languages, mainly a few

Re: The Case Against Autodecode

On Friday, 13 May 2016 at 10:38:09 UTC, Jonathan M Davis wrote: Based on what I've seen in previous conversations on auto-decoding over the past few years (be it in the newsgroup, on github, or at dconf), most of the core devs think that auto-decoding was a major blunder that we continue to

Re: The Case Against Autodecode

On Thursday, 12 May 2016 at 20:15:45 UTC, Walter Bright wrote: 7. Autodecode cannot be used with unicode path/filenames, because it is legal (at least on Linux) to have invalid UTF-8 as filenames. It turns out in the wild that pure Unicode is not universal - there's lots of dirty Unicode that

Re: The Case Against Autodecode

On Thursday, May 12, 2016 13:15:45 Walter Bright via Digitalmars-d wrote: > On 5/12/2016 9:29 AM, Andrei Alexandrescu wrote: > > I am as unclear about the problems of autodecoding as I am about the > > necessity to remove curl. Whenever I ask I hear some arguments that work > > well emotionally

Re: The Case Against Autodecode

On Friday, 13 May 2016 at 06:50:49 UTC, Bill Hicks wrote: not to waste time with D because it's a broken and failed language. D is a better broken thing among all the broken things in this broken world, so it's to be expected to be preferred to spend time on.

Re: The Case Against Autodecode

On Friday, 13 May 2016 at 06:50:49 UTC, Bill Hicks wrote: Wow, that's eleven things wrong with just one tiny element of D, with the potential to cause problems, whether fixed or not. And I get called a troll and other names when I list half a dozen things wrong with D, my posts get

Re: The Case Against Autodecode

On Friday, 13 May 2016 at 01:00:54 UTC, Walter Bright wrote: On 5/12/2016 5:47 PM, Jack Stouffer wrote: D is much less popular now than was Python at the time, and Python 2 problems were more straight forward than the auto-decoding problem. You'll need a very clear migration path, years long

Re: The Case Against Autodecode

On Friday, 13 May 2016 at 00:47:04 UTC, Jack Stouffer wrote: D is much less popular now than was Python at the time, and Python 2 problems were more straight forward than the auto-decoding problem. You'll need a very clear migration path, years long deprecations, and automatic tools in order

Re: The Case Against Autodecode

On Friday, 13 May 2016 at 06:50:49 UTC, Bill Hicks wrote: On Thursday, 12 May 2016 at 20:15:45 UTC, Walter Bright wrote: (...) Wow, that's eleven things wrong with just one tiny element of D, with the potential to cause problems, whether fixed or not. And I get called a troll and other names

Re: The Case Against Autodecode

On Friday, 13 May 2016 at 06:50:49 UTC, Bill Hicks wrote: *rant* Actually, chap, it's the attitude that's the turn-off in your post there. Listing problems in order to improve them, and listing problems to convince people something is a waste of time are incompatible mindsets around here.

Re: The Case Against Autodecode

On Thursday, 12 May 2016 at 20:15:45 UTC, Walter Bright wrote: Here are some that are not matters of opinion. 1. Ranges of characters do not autodecode, but arrays of characters do. This is a glaring inconsistency. 2. Every time one wants an algorithm to work with both strings and ranges,

Re: The Case Against Autodecode

On Thursday, 12 May 2016 at 20:15:45 UTC, Walter Bright wrote: 2. Every time one wants an algorithm to work with both strings and ranges, you wind up special casing the strings to defeat the autodecoding, or to decode the ranges. Having to constantly special case it makes for more special

Re: The Case Against Autodecode

On 5/12/2016 5:47 PM, Jack Stouffer wrote: D is much less popular now than was Python at the time, and Python 2 problems were more straight forward than the auto-decoding problem. You'll need a very clear migration path, years long deprecations, and automatic tools in order to make the

Re: The Case Against Autodecode

On Friday, 13 May 2016 at 00:47:04 UTC, Jack Stouffer wrote: I'm not exaggerating here. Python, a language which was much more popular than D at the time, came out with two versions in 2008: Python 2.7 which had numerous unicode problems, and Python 3.0 which fixed those problems. Almost eight

Re: The Case Against Autodecode

On 5/12/2016 4:52 PM, Marco Leise wrote: I'd like 'string' to mean valid UTF-8 in D as far as the encoding goes. A filename should not be a 'string'. I would have agreed with you in the past, but more and more it just doesn't seem practical. UTF-8 is dirty in the real world, and D code will

Re: The Case Against Autodecode

On Thursday, 12 May 2016 at 20:15:45 UTC, Walter Bright wrote: Here are some that are not matters of opinion. If you're serious about removing auto-decoding, which I think you and others have shown has merits, you have to the THE SIMPLEST migration path ever, or you will kill D. I'm talking

Re: The Case Against Autodecode

Am Thu, 12 May 2016 13:15:45 -0700 schrieb Walter Bright : > 7. Autodecode cannot be used with unicode path/filenames, because it is legal > (at least on Linux) to have invalid UTF-8 as filenames. More precisely they are byte strings with '/' reserved to separate

Re: The Case Against Autodecode

On 5/12/2016 4:23 PM, Daniel Kozak wrote: But what I am really piss of is that current string type is alias to immutable(char)[] (so it is not usable at all). This is really problem for me. Because this make working on array of chars almost impossible. Even char[] is unusable. So I am force to

Re: The Case Against Autodecode

On Thursday, 12 May 2016 at 20:15:45 UTC, Walter Bright wrote: On 5/12/2016 9:29 AM, Andrei Alexandrescu wrote: > I am as unclear about the problems of autodecoding as I am about the necessity > to remove curl. Whenever I ask I hear some arguments that work well emotionally > but are scant on

Re: The Case Against Autodecode

On Thu, May 12, 2016 at 08:24:23PM +, Vladimir Panteleev via Digitalmars-d wrote: [...] > 12. The result of autodecoding, a range of Unicode code points, is > rarely actually useful, and code that relies on autodecoding is rarely > actually, universally correct. Graphemes are occasionally

Re: The Case Against Autodecode

On Thu, May 12, 2016 at 08:24:23PM +, Vladimir Panteleev via Digitalmars-d wrote: > On Thursday, 12 May 2016 at 20:15:45 UTC, Walter Bright wrote: [...] > >1. Ranges of characters do not autodecode, but arrays of characters > >do. This is a glaring inconsistency. > > > >2. Every time one

The Case Against Autodecode

On 5/12/2016 9:29 AM, Andrei Alexandrescu wrote: > I am as unclear about the problems of autodecoding as I am about the necessity > to remove curl. Whenever I ask I hear some arguments that work well emotionally > but are scant on reason and engineering. Maybe it's time to rehash them? I just >

Re: The Case Against Autodecode

On Thursday, 12 May 2016 at 20:15:45 UTC, Walter Bright wrote: On 5/12/2016 9:29 AM, Andrei Alexandrescu wrote: > I am as unclear about the problems of autodecoding as I am about the necessity > to remove curl. Whenever I ask I hear some arguments that work well emotionally > but are scant on

<    1   2   3   4   5