Re: So, About That Official Blog...

Static generator assumes there wouldn't be any comment system for blog entries? At least a link to the corresponding forum topic, line phoronix.com? As of Tumblr, does it allow for arbitrary domain name? whatever.tublr.com looks a bit unpresentably. blog.dalng.org definitely would be better.

Re: Why simple code using Rebindable doesn't compile ?

On Monday, 30 May 2016 at 21:32:46 UTC, Alex Parrill wrote: On Monday, 30 May 2016 at 10:09:19 UTC, chmike wrote: Why can't info() return a Rebindable!(immutable(InfoImpl)) ? What do you mean? `info` returns an `immutable(InfoImpl)`, not a `Rebindable!(immutable(InfoImpl))`. Rebindable

Re: So, About That Official Blog...

On Tuesday, 31 May 2016 at 02:06:42 UTC, Seb wrote: Let's just make a simple decision, create the blog and create articles. As long as we don't get any content, this doesn't matter anyways! There will be a relevant announcement soonish.

Re: The Case Against Autodecode

On 5/30/16 7:52 PM, Seb wrote: On Monday, 30 May 2016 at 21:39:14 UTC, Vladimir Panteleev wrote: On Monday, 30 May 2016 at 16:34:49 UTC, Jack Stouffer wrote: On Monday, 30 May 2016 at 16:25:20 UTC, Nick Sabalausky wrote: D1 -> D2 was a vastly more disruptive change than getting rid of

Re: The Case Against Autodecode

On 5/30/16 5:51 PM, Walter Bright wrote: On 5/30/2016 8:34 AM, Marc Schütz wrote: In an ideal world, we'd also want to change the way `length` and `opIndex` work, Why? strings are arrays of code units. All the trouble comes from erratically pretending otherwise. That's not an argument.

Re: The Case Against Autodecode

On 5/30/16 6:00 PM, 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 correctly (at least with regard to handling code units). Yup. It isn't hard at all to use arrays of

[Issue 16104] Unions should allow fields with destructors, postblits, and invariants

https://issues.dlang.org/show_bug.cgi?id=16104 --- Comment #4 from Andrei Alexandrescu --- (In reply to Walter Bright from comment #2) > Consider: > > struct S { ~this(); } > struct T { S s; } > > The compiler will automatically create a destructor for T that will call

[Issue 16104] Unions should allow fields with destructors, postblits, and invariants

https://issues.dlang.org/show_bug.cgi?id=16104 --- Comment #3 from Andrei Alexandrescu --- (In reply to Walter Bright from comment #1) > In C++: > > struct S { ~S(); }; > union U { S s; }; > > g++ -c foo.cpp > foo.cpp:2:14: error: member 'S U::s' with destructor not

Re: The Case Against Autodecode

On Monday, 30 May 2016 at 21:39:14 UTC, Vladimir Panteleev wrote: Perhaps it would be worth trying to silently remove autodecoding and seeing how much of Phobos breaks, as an experiment. Has this been tried before? Did it, the results are a large number of phobos modules fail to compile

[Issue 16104] Unions should allow fields with destructors, postblits, and invariants

https://issues.dlang.org/show_bug.cgi?id=16104 --- Comment #2 from Walter Bright --- Consider: struct S { ~this(); } struct T { S s; } The compiler will automatically create a destructor for T that will call the destructor for s, or will add code to do that to the

Re: Button: A fast, correct, and elegantly simple build system.

On 31/05/2016 7:16 AM, Jason White wrote: I am pleased to finally announce the build system I've been slowly working on for over a year in my spare time: Docs: http://jasonwhite.github.io/button/ Source: https://github.com/jasonwhite/button Features: - Correct incremental builds. -

[Issue 16104] Unions should allow fields with destructors, postblits, and invariants

https://issues.dlang.org/show_bug.cgi?id=16104 Walter Bright changed: What|Removed |Added CC|

[Issue 16104] New: Unions should allow fields with destructors, postblits, and invariants

https://issues.dlang.org/show_bug.cgi?id=16104 Issue ID: 16104 Summary: Unions should allow fields with destructors, postblits, and invariants Product: D Version: D2 Hardware: x86_64 OS: Linux

Re: The Case Against Autodecode

On 05/30/2016 04:30 PM, Timon Gehr wrote: In D, enum does not mean enumeration, const does not mean constant, pure is not pure, lazy is not lazy, and char does not mean character. My new favorite quote :)

Re: So, About That Official Blog...

On Monday, 9 May 2016 at 12:31:37 UTC, Seb wrote: On Sunday, 8 May 2016 at 20:31:26 UTC, Nick Sabalausky wrote: [...] Guys - KISS! During the time we already spent in this thread, we could have written least five great blog entries! Therefore +1 for static site generators - they keep stuff

Re: Button: A fast, correct, and elegantly simple build system.

On Monday, 30 May 2016 at 19:16:50 UTC, Jason White wrote: I am pleased to finally announce the build system I've been slowly working on for over a year in my spare time: [...] [snip] Button: - https://github.com/jasonwhite/darg (A command-line parser) - https://github.com/jasonwhite/io

Re: faster splitter

On 05/30/2016 06:16 PM, qznc wrote: What function call should be replaced with inline code? The call to computeSkip. Overall, I'm very confused and displeased by the benchmark right now. I agree it's difficult to characterize the behavior of substring search with one number. There are

Re: The Case Against Autodecode

On Monday, 30 May 2016 at 21:39:14 UTC, Vladimir Panteleev wrote: On Monday, 30 May 2016 at 16:34:49 UTC, Jack Stouffer wrote: On Monday, 30 May 2016 at 16:25:20 UTC, Nick Sabalausky wrote: D1 -> D2 was a vastly more disruptive change than getting rid of auto-decoding would be. Don't be so

Re: Operator overloading through UFCS doesn't work

Here's one more vote for extending UFCS to operator overloading. Elie wrote that it's "a restriction that seems pointless and arbitrary"... which summarizes my own thoughts rather well, too. There are certainly concerning scenarios that can arise from making this change, but the correct way

Re: Why aren't overloaded nested functions allowed?

On Monday, 30 May 2016 at 16:22:26 UTC, Max Samukha wrote: From the spec (https://dlang.org/spec/function.html#nested): "Nested functions cannot be overloaded." Anybody knows what's the rationale? I'm guessing it's related to - Unlike module level declarations, declarations within function

Re: The Case Against Autodecode

A relevant thread in the Rust bug tracker I remember from three years ago: https://github.com/rust-lang/rust/issues/7043 May it be of inspiration. -- Marco

Re: The Case Against Autodecode

> 4: Indonesians* shall be converted to a sane alphabet *Correction: Koreans (2-4 Hangul syllables (code points) form each letter) -- Marco

Re: faster splitter

On Monday, 30 May 2016 at 20:08:46 UTC, Andrei Alexandrescu wrote: On 05/30/2016 04:00 PM, Chris wrote: ./benchmark.dmd std: 178 ±31+36 (4475) -29 (5344) manual: 167 ±46+82 (2883) -32 (7054) qznc: 114 ±7 +18 (1990) -5 (7288) Chris: 228 ±49+82 (3050)

Re: The Case Against Autodecode

Am Fri, 27 May 2016 15:47:32 +0200 schrieb ag0aep6g : > On 05/27/2016 03:32 PM, Andrei Alexandrescu wrote: > >>> However the following do require autodecoding: > >>> > >>> s.walkLength > >>> s.count!(c => !"!()-;:,.?".canFind(c)) // non-punctuation > >>> s.count!(c => c >=

[Issue 16098] align(32) not respected for stack variables

https://issues.dlang.org/show_bug.cgi?id=16098 Ketmar Dark changed: What|Removed |Added CC|

Re: The Case Against Autodecode

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 correctly (at least with regard to handling code units). Yup. It isn't hard at all to use arrays of codeunits correctly.

Re: The Case Against Autodecode

On 5/30/2016 8:34 AM, Marc Schütz wrote: In an ideal world, we'd also want to change the way `length` and `opIndex` work, Why? strings are arrays of code units. All the trouble comes from erratically pretending otherwise.

Re: Why do some T.init evaluate to true while others to false?

On Friday, 27 May 2016 at 15:49:16 UTC, ArturG wrote: On Friday, 27 May 2016 at 15:24:18 UTC, Adam D. Ruppe wrote: On Friday, 27 May 2016 at 15:19:50 UTC, ArturG wrote: yes but i have to check for that when some one does Why? This is no different than if they set any of the other four

Re: The Case Against Autodecode

On Monday, 30 May 2016 at 16:34:49 UTC, Jack Stouffer wrote: On Monday, 30 May 2016 at 16:25:20 UTC, Nick Sabalausky wrote: D1 -> D2 was a vastly more disruptive change than getting rid of auto-decoding would be. Don't be so sure. All string handling code would become broken, even if it

Re: The Case Against Autodecode

On 5/30/2016 12:52 PM, H. S. Teoh via Digitalmars-d wrote: If I ever had to write string-heavy code, I'd probably fork Phobos just so I can get decent performance. Just sayin'. When I wrote Warp, the only point of which was speed, I couldn't use phobos because of autodecoding. I have since

Re: Why simple code using Rebindable doesn't compile ?

On Monday, 30 May 2016 at 10:09:19 UTC, chmike wrote: This code compile, but array appending doesn't work alias Rebindable!(immutable(InfoImpl)) Info; class InfoImpl { void foo() {} static immutable(InfoImpl) info() { __gshared immutable InfoImpl x = new immutable

Re: The Case Against Autodecode

Am Mon, 30 May 2016 17:14:47 + schrieb Andrew Godfrey : > I like "make string iteration explicit" but I wonder about other > constructs. E.g. What about "sort an array of strings"? How would > you tell a generic sort function whether you want it to interpret > strings by code

Re: Button: A fast, correct, and elegantly simple build system.

On Monday, 30 May 2016 at 20:58:51 UTC, poliklosio wrote: - Lua is the primary build description language. Why not D? Generating the JSON build description should entirely deterministic. With Lua, this can be guaranteed. You can create a sandbox where only certain operations are permitted.

[Issue 16085] wrong visibility warning for overloaded alias symbol

https://issues.dlang.org/show_bug.cgi?id=16085 Walter Bright changed: What|Removed |Added CC|

Re: Button: A fast, correct, and elegantly simple build system.

On Monday, 30 May 2016 at 19:16:50 UTC, Jason White wrote: I am pleased to finally announce the build system I've been slowly working on for over a year in my spare time: Docs: http://jasonwhite.github.io/button/ Source: https://github.com/jasonwhite/button Great news! Love to see

Re: The Case Against Autodecode

On 30.05.2016 21:28, Andrei Alexandrescu wrote: On 05/30/2016 03:04 PM, Timon Gehr wrote: On 30.05.2016 18:01, Andrei Alexandrescu wrote: On 05/28/2016 03:04 PM, Walter Bright wrote: On 5/28/2016 5:04 AM, Andrei Alexandrescu wrote: So it harkens back to the original mistake: strings should

Re: faster splitter

On 05/30/2016 04:00 PM, Chris wrote: ./benchmark.dmd std: 178 ±31+36 (4475) -29 (5344) manual: 167 ±46+82 (2883) -32 (7054) qznc: 114 ±7 +18 (1990) -5 (7288) Chris: 228 ±49+82 (3050) -35 (6780) Andrei: 103 ±5 +47 ( 658) -2 (9295) (avg

Re: The Case Against Autodecode

On Monday, 30 May 2016 at 18:26:32 UTC, Adam D. Ruppe wrote: On Monday, 30 May 2016 at 17:14:47 UTC, Andrew Godfrey wrote: I like "make string iteration explicit" but I wonder about other constructs. E.g. What about "sort an array of strings"? How would you tell a generic sort function whether

Re: faster splitter

On Monday, 30 May 2016 at 18:57:15 UTC, Chris wrote: On Monday, 30 May 2016 at 18:20:39 UTC, Andrei Alexandrescu wrote: Please throw this hat into the ring as well: it should improve average search on large vocabulary dramatically. https://dpaste.dzfl.pl/dc8dc6e1eb53 It uses a BM-inspired

Re: The Case Against Autodecode

On Mon, May 30, 2016 at 03:28:38PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: > On 05/30/2016 03:04 PM, Timon Gehr wrote: > > On 30.05.2016 18:01, Andrei Alexandrescu wrote: > > > On 05/28/2016 03:04 PM, Walter Bright wrote: > > > > On 5/28/2016 5:04 AM, Andrei Alexandrescu wrote: > > >

[Issue 16102] [REG2.070] struct dtor replace value on stack

https://issues.dlang.org/show_bug.cgi?id=16102 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com

[Issue 16102] struct dtor replace value on stack

https://issues.dlang.org/show_bug.cgi?id=16102 Oleg B changed: What|Removed |Added Keywords||wrong-code --

Re: D, GTK, Qt, wx,…

On Sunday, 29 May 2016 at 11:03:36 UTC, Russel Winder wrote: Is there even a wxD? Or perhaps there is an alternative that fits the bill of being production ready now, and either gives the same UI across all platforms or provides a platform UI with no change of source code, just a

Re: The Case Against Autodecode

On 05/30/2016 03:04 PM, Timon Gehr wrote: On 30.05.2016 18:01, Andrei Alexandrescu wrote: On 05/28/2016 03:04 PM, Walter Bright wrote: On 5/28/2016 5:04 AM, Andrei Alexandrescu wrote: So it harkens back to the original mistake: strings should NOT be arrays with the respective primitives. An

Re: The Case Against Autodecode

Am Mon, 30 May 2016 17:35:36 + schrieb Chris : > I was actually talking about ICU with a colleague today. Could it > be that Unicode itself is broken? I've often heard criticism of > Unicode but never looked into it. You have to compare to the situation before, when every

[Issue 16103] New: DDOC module-level function list descriptions refer to unknown parameter names

https://issues.dlang.org/show_bug.cgi?id=16103 Issue ID: 16103 Summary: DDOC module-level function list descriptions refer to unknown parameter names Product: D Version: D2 Hardware: All OS: All

[Issue 16102] New: struct dtor replace value on stack

https://issues.dlang.org/show_bug.cgi?id=16102 Issue ID: 16102 Summary: struct dtor replace value on stack Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: major Priority:

Re: How to improve autodecoding? (Was: The Case Against Autodecode)

On 05/30/2016 03:00 PM, Jack Stouffer wrote: On Monday, 30 May 2016 at 18:24:23 UTC, Andrei Alexandrescu wrote: That kind of makes this thread less productive than "How to improve autodecoding?" -- Andrei Please don't misunderstand, I'm for fixing string behavior. Surely the

Button: A fast, correct, and elegantly simple build system.

I am pleased to finally announce the build system I've been slowly working on for over a year in my spare time: Docs: http://jasonwhite.github.io/button/ Source: https://github.com/jasonwhite/button Features: - Correct incremental builds. - Automatic dependency detection (for any

Re: Why do some T.init evaluate to true while others to false?

On Friday, 27 May 2016 at 14:48:59 UTC, Adam D. Ruppe wrote: On Friday, 27 May 2016 at 14:43:47 UTC, ArturG wrote: if(value is typeof(value).init) ... that still requiers a special case for floating points, arrays and optionally empty string literals. Have you tried? That should work

Re: The Case Against Autodecode

On 30.05.2016 18:01, Andrei Alexandrescu wrote: On 05/28/2016 03:04 PM, Walter Bright wrote: On 5/28/2016 5:04 AM, Andrei Alexandrescu wrote: So it harkens back to the original mistake: strings should NOT be arrays with the respective primitives. An array of code units provides consistency,

Re: Copyright for Phobos to D Foundation

On Monday, 30 May 2016 at 16:03:05 UTC, Andrei Alexandrescu wrote: On 05/28/2016 01:50 PM, Seb wrote: Ping @WalterBright, @andralex & people with legal experience. I have none, sorry. We have an attorney at least temporarily to help our nonprofit status application, I can forward precise

Re: How to improve autodecoding? (Was: The Case Against Autodecode)

On Monday, 30 May 2016 at 18:24:23 UTC, Andrei Alexandrescu wrote: That kind of makes this thread less productive than "How to improve autodecoding?" -- Andrei Please don't misunderstand, I'm for fixing string behavior. But, let's not pretend that this wouldn't be one of the (if not the)

Re: faster splitter

On Monday, 30 May 2016 at 18:20:39 UTC, Andrei Alexandrescu wrote: Please throw this hat into the ring as well: it should improve average search on large vocabulary dramatically. https://dpaste.dzfl.pl/dc8dc6e1eb53 It uses a BM-inspired trick - once the last characters matched, if the

Re: Transient ranges

On Monday, 30 May 2016 at 12:53:07 UTC, Steven Schveighoffer wrote: On 5/30/16 5:35 AM, Dicebot wrote: On Sunday, 29 May 2016 at 17:25:47 UTC, Steven Schveighoffer wrote: What problems are solvable only by not caching the front element? I can't think of any. As far as I know, currently it

Re: The Case Against Autodecode

On Monday, 30 May 2016 at 16:03:03 UTC, Marco Leise wrote: When on the other hand you work with real world international text, you'll want to work with graphemes. Actually, my main rule of thumb is: don't mess with strings. Get them from the user, store them without modification, spit them

Re: The Case Against Autodecode

On Monday, 30 May 2016 at 17:14:47 UTC, Andrew Godfrey wrote: I like "make string iteration explicit" but I wonder about other constructs. E.g. What about "sort an array of strings"? How would you tell a generic sort function whether you want it to interpret strings by code unit vs code point

Re: How to improve autodecoding? (Was: The Case Against Autodecode)

On 30-May-2016 21:24, Andrei Alexandrescu wrote: On 05/30/2016 12:34 PM, Jack Stouffer wrote: On Monday, 30 May 2016 at 16:25:20 UTC, Nick Sabalausky wrote: D1 -> D2 was a vastly more disruptive change than getting rid of auto-decoding would be. Don't be so sure. All string handling code

Re: The Case Against Autodecode

On Monday, 30 May 2016 at 14:35:03 UTC, Seb wrote: That's a great idea - the compiler should also issue deprecation warnings when I try to do things like: I don't agree on changing those. Indexing and slicing a char[] is really useful and actually not hard to do correctly (at least with

[Issue 16085] wrong visibility warning for overloaded alias symbol

https://issues.dlang.org/show_bug.cgi?id=16085 Martin Nowak changed: What|Removed |Added Summary|Imported name causes lookup |wrong visibility warning

How to improve autodecoding? (Was: The Case Against Autodecode)

On 05/30/2016 12:34 PM, Jack Stouffer wrote: On Monday, 30 May 2016 at 16:25:20 UTC, Nick Sabalausky wrote: D1 -> D2 was a vastly more disruptive change than getting rid of auto-decoding would be. Don't be so sure. All string handling code would become broken, even if it appears to work at

Re: The Case Against Autodecode

On 05/30/2016 12:25 PM, Nick Sabalausky wrote: On 05/29/2016 09:58 PM, Jack Stouffer wrote: The problem is not active users. The problem is companies who have > 10K LOC and libraries that are no longer maintained. E.g. It took Sociomantic eight years after D2's release to switch only a few

Re: faster splitter

On 05/30/2016 05:31 AM, qznc wrote: On Sunday, 29 May 2016 at 21:07:21 UTC, qznc wrote: When looking at the assembly I don't like the single-byte loads. Since string (ubyte[] here) is of extraordinary importance, it should be worthwhile to use word loads [0] instead. Really fancy would be SSE.

SQLite-D goes beta!

It is my pleasure to announce that I now consider SQLite-D to be in Beta stage. The reader is now stable enough to read all the test tables I have been given. The fact that it took around 20 minutes to complete index-tree support convinced mt that I have chosen a solid design. I have

[Issue 16101] New: ddoc inserts empty section with newline

https://issues.dlang.org/show_bug.cgi?id=16101 Issue ID: 16101 Summary: ddoc inserts empty section with newline Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: minor

Re: String compare in words?

I didn't check assembly for '=='. What I have seen is that struct comparison in dmd is implemented as byte per byte compare even if the struct is 64bit long (e.g. Rebindable). I suppose dmd uses this strategy because struct/array may not be 64bit aligned, or they could have different

Re: The Case Against Autodecode

On Monday, 30 May 2016 at 16:03:03 UTC, Marco Leise wrote: *** http://site.icu-project.org/home#TOC-What-is-ICU- I was actually talking about ICU with a colleague today. Could it be that Unicode itself is broken? I've often heard criticism of Unicode but never looked into it.

Re: The Case Against Autodecode

I like "make string iteration explicit" but I wonder about other constructs. E.g. What about "sort an array of strings"? How would you tell a generic sort function whether you want it to interpret strings by code unit vs code point vs grapheme?

[Issue 16100] Error with -O of struct enumeration value and comma operator

https://issues.dlang.org/show_bug.cgi?id=16100 --- Comment #1 from Johan Engelen --- Also fails with DMD 2.068.2. (important: "-O" must be used, without "-O" it works) --

Re: Transient ranges

On Mon, May 30, 2016 at 09:26:35AM -0400, Steven Schveighoffer via Digitalmars-d wrote: > On 5/30/16 12:17 AM, Jonathan M Davis via Digitalmars-d wrote: [...] > > Having byLine not copy its buffer is fine. Having it be a range is > > not. Algorithms in general just do not play well with that > >

[Issue 16100] New: Error with -O of struct enumeration value and comma operator

https://issues.dlang.org/show_bug.cgi?id=16100 Issue ID: 16100 Summary: Error with -O of struct enumeration value and comma operator Product: D Version: D2 Hardware: All OS: All Status: NEW

Re: The Case Against Autodecode

On Monday, 30 May 2016 at 16:25:20 UTC, Nick Sabalausky wrote: D1 -> D2 was a vastly more disruptive change than getting rid of auto-decoding would be. Don't be so sure. All string handling code would become broken, even if it appears to work at first.

Re: The Case Against Autodecode

Am Thu, 26 May 2016 16:23:16 -0700 schrieb "H. S. Teoh via Digitalmars-d" : > On Thu, May 26, 2016 at 12:00:54PM -0400, Andrei Alexandrescu via > Digitalmars-d wrote: > [...] > > s.walkLength > > s.count!(c => !"!()-;:,.?".canFind(c)) // non-punctuation > >

Re: The Case Against Autodecode

On 05/29/2016 09:58 PM, Jack Stouffer wrote: The problem is not active users. The problem is companies who have > 10K LOC and libraries that are no longer maintained. E.g. It took Sociomantic eight years after D2's release to switch only a few parts of their projects to D2. With the loss of old

Why aren't overloaded nested functions allowed?

From the spec (https://dlang.org/spec/function.html#nested): "Nested functions cannot be overloaded." Anybody knows what's the rationale?

Re: Avoid GC with closures

On Sunday, 29 May 2016 at 11:16:57 UTC, Dicebot wrote: On 05/28/2016 09:58 PM, Iakh wrote: Yeah. It doesn't capture any context. But once it does it would be an error. Custom allocators are not very suitable for things like closures because of undefined lifetime. Even if it was allowed to

Re: Copyright for Phobos to D Foundation

On 05/28/2016 01:50 PM, Seb wrote: Ping @WalterBright, @andralex & people with legal experience. I have none, sorry. We have an attorney at least temporarily to help our nonprofit status application, I can forward precise questions if needed. -- Andrei

Re: The Case Against Autodecode

Am Mon, 30 May 2016 09:26:09 + schrieb Chris : > If it's true that auto decode is unnecessary in many cases, then > it shouldn't affect the whole code base. But I might be mistaken > here. Maybe we should make a list of the functions where auto > decode does make a

Re: The Case Against Autodecode

On 05/28/2016 03:04 PM, Walter Bright wrote: On 5/28/2016 5:04 AM, Andrei Alexandrescu wrote: So it harkens back to the original mistake: strings should NOT be arrays with the respective primitives. An array of code units provides consistency, predictability, flexibility, and performance.

Re: The Case Against Autodecode

On 05/29/2016 04:47 PM, H. S. Teoh via Digitalmars-d wrote: It depends on what you're trying to accomplish. That's the point we're trying to get at. For some operations, working with code points makes the most sense. But for other operations, it does not. There is no one representation that is

Re: Transient ranges

On 05/30/2016 12:22 AM, Jack Stouffer wrote: On Sunday, 29 May 2016 at 17:36:24 UTC, Steven Schveighoffer wrote: Wholly disagree. If we didn't cache the element, D would be a laughingstock of performance-minded tests. byLine already is a laughingstock performance wise:

[Issue 11810] std.stdio.byLine/readln performance is very bad

https://issues.dlang.org/show_bug.cgi?id=11810 Andrei Alexandrescu changed: What|Removed |Added Status|NEW |RESOLVED

Re: Transient ranges

On 05/30/2016 11:22 AM, Steven Schveighoffer wrote: On Monday, 30 May 2016 at 15:12:41 UTC, Andrei Alexandrescu wrote: On 05/30/2016 09:30 AM, Steven Schveighoffer wrote: My iopipe library is 2x as fast. Cool! What is the trick to the speedup? -- Andrei Direct buffer access and not using

[Issue 16099] New: Inconsistent rules for overloading lambdas

https://issues.dlang.org/show_bug.cgi?id=16099 Issue ID: 16099 Summary: Inconsistent rules for overloading lambdas Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal

Re: The Case Against Autodecode

On Monday, 30 May 2016 at 14:56:36 UTC, ag0aep6g wrote: All this is only sensible when we move to a dedicated string type that's not just an alias of `immutable(char)[]`. `immutable(char)[]` explicitly is an array of code units. It would not be acceptable, in my opinion, if the normal array

Re: Transient ranges

On Monday, 30 May 2016 at 15:12:41 UTC, Andrei Alexandrescu wrote: On 05/30/2016 09:30 AM, Steven Schveighoffer wrote: My iopipe library is 2x as fast. Cool! What is the trick to the speedup? -- Andrei Direct buffer access and not using FILE * as a base. -Steve

Re: Operator overloading through UFCS doesn't work

On Sunday, 29 May 2016 at 07:18:10 UTC, Jonathan M Davis wrote: On Friday, May 27, 2016 09:08:20 Marc Schütz via Digitalmars-d-learn wrote: On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis wrote: > The difference is that it's impossible to do > 10.opBinary!"+"(15), so if you're

Re: Transient ranges

On 05/30/2016 09:26 AM, Steven Schveighoffer wrote: Here is how I think about it: the front element is valid and stable until you call popFront. After that, anything goes for the old front. Yah, we should have formal language in the library reference about this. -- Andrei

Re: Transient ranges

On 05/30/2016 09:30 AM, Steven Schveighoffer wrote: My iopipe library is 2x as fast. Cool! What is the trick to the speedup? -- Andrei

[Issue 16085] Imported name causes lookup deprecation warning even if masked by member name

https://issues.dlang.org/show_bug.cgi?id=16085 --- Comment #7 from Andrei Alexandrescu --- (In reply to Martin Nowak from comment #6) > (In reply to Andrei Alexandrescu from comment #5) > > The issue is subtler than that (I'd agree the snippet above is a clear cut). > > The

Re: Free the DMD backend

On Monday, 30 May 2016 at 14:51:48 UTC, Matthias Klumpp wrote: On Sunday, 29 May 2016 at 10:56:57 UTC, Russel Winder wrote: On Sun, 2016-05-29 at 04:08 +, Joakim via Digitalmars-d wrote: […] It would be nice if that happened, but Walter has said Symantec isn't interested.  Aren't ldc

Re: Our Sister

Am Sat, 28 May 2016 14:15:45 +1000 schrieb Manu via Digitalmars-d : > On 28 May 2016 at 10:16, Adam D. Ruppe via Digitalmars-d > wrote: > > On Friday, 27 May 2016 at 21:51:59 UTC, Seb wrote: > >> > >> not if [] would be ref-counted too

Re: The Case Against Autodecode

On 05/30/2016 04:35 PM, Seb wrote: That's a great idea - the compiler should also issue deprecation warnings when I try to do things like: string a = "你好"; a[1]; // deprecation: direct access to a Unicode string is highly error-prone. Please specify the type of access. More details

Re: Free the DMD backend

On Sunday, 29 May 2016 at 10:56:57 UTC, Russel Winder wrote: On Sun, 2016-05-29 at 04:08 +, Joakim via Digitalmars-d wrote: […] It would be nice if that happened, but Walter has said Symantec isn't interested.  Aren't ldc and GDC enough? This is why LDC should be seen in the D

[Issue 16085] Imported name causes lookup deprecation warning even if masked by member name

https://issues.dlang.org/show_bug.cgi?id=16085 --- Comment #6 from Martin Nowak --- (In reply to Andrei Alexandrescu from comment #5) > The issue is subtler than that (I'd agree the snippet above is a clear cut). > The thing is Bucketizer _also_ defines its own reallocate: Ah, I

Re: The Case Against Autodecode

On Monday, 30 May 2016 at 12:59:08 UTC, Adam D. Ruppe wrote: On Monday, 30 May 2016 at 12:45:27 UTC, Andrei Alexandrescu wrote: That's... what I said. -- Andrei You said "not arrays", he said "not ranges". So that just means making the std.range.primitives.popFront and front add a

[Issue 16085] Imported name causes lookup deprecation warning even if masked by member name

https://issues.dlang.org/show_bug.cgi?id=16085 Andrei Alexandrescu changed: What|Removed |Added Status|RESOLVED|REOPENED

[Issue 15857] incorrect checkimports mismatch for overload sets

https://issues.dlang.org/show_bug.cgi?id=15857 --- Comment #8 from Jacob Carlborg --- This is not fixed in v2.071.1-b2. --

Re: aliasing expressions and identifiers

On Monday, 30 May 2016 at 14:18:38 UTC, Nick Treleaven wrote: On Monday, 30 May 2016 at 10:55:57 UTC, Marc Schütz wrote: auto tmp = stdin.byLine; auto lines = tmp.array; Here, `lines` contains references to the buffer owned by `tmp`, but doesn't escape (assuming `array` takes its

[Issue 16098] New: align(32) not respected for stack variables

https://issues.dlang.org/show_bug.cgi?id=16098 Issue ID: 16098 Summary: align(32) not respected for stack variables Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Keywords: C++, SIMD

  1   2   >