ReQL: pluses and minuses of pipeline-style queries

Found this on reddit a few days ago:

A good discussion of the pros and cons of pipeline-style queries (the 
ReQL query language reminiscent of D's algorithms/ranges) vs. classic SQL.


cym13 via Digitalmars-d | 24 Apr 23:47 2015

Re: A valid code that won't run?

On Friday, 24 April 2015 at 21:42:43 UTC, Daniel Kozak wrote:
> On Fri, 24 Apr 2015 16:52:16 -0400
> Steven Schveighoffer via Digitalmars-d 
> <digitalmars-d <at>> wrote:
>> On 4/24/15 4:36 PM, Dicebot wrote:
>> > On Friday, 24 April 2015 at 20:27:28 UTC, Steven 
>> > Schveighoffer wrote:
>> >> If pragma(lib, "libcurl"); doesn't work normally, then we 
>> >> should
>> >> remove, and put it in dub.
>> >
>> > It was a historical mistake, discussed many time over and 
>> > over. Yes, it
>> > shouldn't be in Phobos. No, we can't remove it now that 
>> > easily.
>> deprecated("Please use dub for curl");
>> module
>> // this will cause an error until you install the binding, 
>> then you can
>> // go through your imports and update them.
>> public import some.dub.project;
>> > As for pragma(lib) - it can never work "normally". Linking 
>> > 3d-party
>> > libraries is very platform-specific task that causes great 
>> > deal of
(Continue reading)

Re: Range of chars (narrow string ranges)

On 4/24/2015 11:52 AM, H. S. Teoh via Digitalmars-d wrote:
> I really wish we would just *make the darn decision* already, whether to
> kill off autodecoding or not, and MAKE IT CONSISTENT ACROSS PHOBOS,
> instead of introducing this schizophrenic dichotomy where some functions
> give you a range of dchar while others give you a range of char/wchar,
> and the two don't work well together. This is totally going to make a
> laughing stock of D one day.

Some facts:

1. When I started D, there was a lot of speculation about whether the world 
would settle on UTF8, UTF16, or UTF32. So D supports natively all three. Time 
has shown, however, that UTF8 has pretty much won. wchar only exists for Windows 
API and Java, dchar strings pretty much don't exist in the wild.

2. dchar is very useful as a character type, but not as a string type.

3. Pretty much none of the algorithms in Phobos work when presented with a range 
of chars or wchars. This is not even documented.

4. Autodecoding is inefficient, especially considering that few algorithms 
actually need decoding. Re-encoding the result back to UTF8 is another inefficiency.

I'm afraid we are stuck with autodecoding, as taking it out may be far too 

But all is not lost. The Phobos algorithms can all be fixed to not care about 
autodecoding. The changes I've made to std.string all reflect that.
(Continue reading)

Range of chars (narrow string ranges)

Just want to make this a bit more visible.

We just added entabber to std.phobos, and AFAIK, it's the first range
algorithm that transforms narrow strings to a range of chars, instead of
decoding the original string and returning a range of dchars.

Most of phobos can't handle such ranges like strings and you'd have to
decode them using byDchar to work with them.

Re: A valid code that won't run?

On 4/24/15 1:37 PM, Iain Buclaw via Digitalmars-d wrote:

> You need to explicitly link third party libraries.

You shouldn't need to explicitly link anything that comes out of phobos IMO.


cym13 via Digitalmars-d | 24 Apr 19:05 2015

A valid code that won't run?

I have here a little snippet that just won't run (many issues in 

void main(string[] args) {
     import std.stdio,, std.algorithm;

          .filter!(q{ a.canFind("D") })

Let's start with ldc:

$ ldc --version
LDC - the LLVM D compiler (0.15.1):
       based on DMD v2.066.1 and LLVM 3.5.1
         Default target: x86_64-unknown-linux-gnu
         Host CPU: corei7

$ ldc test.d
test.d(11): Error: no property 'each' for type 
'FilterResult!(unaryFun, SyncLineInputRange)'

Same with gdc:

$ gdc --version
gdc (GCC) 4.9.2
(Continue reading)

anonymous via Digitalmars-d | 24 Apr 17:05 2015

GC.malloc is pure - wat

GC.malloc is marked pure. But it isn't, is it?

This should hold for a pure function:
     assert(f(x) == f(x));
This fails with GC.malloc, of course.

Or consider this:
     auto v = f(x);
     auto w = f(x);
When f is pure, a compiler should be free to reuse the value of v 
for w. That's no good with GC.malloc, obviously.

Chris via Digitalmars-d | 24 Apr 13:00 2015

Performance of loops

I tested the performance of three types of loops (see code 
below). It turns out that the fastest loop is the "plainLoop". 
Unless my examples are completely screwed up, the difference 
between "plainLoop" and the other two loops is gigantic (e.g.):

9 ms, 149 μs, and 4 hnsecs  // foreach (const ref w)
9 ms, 77 μs, and 8 hnsecs   // foreach (ref w)
1 ms, 183 μs, and 6 hnsecs  // foreach (w)

with -release -inline -O -boundscheck=off

8 ms, 492 μs, and 3 hnsecs
8 ms, 287 μs, and 1 hnsec
341 μs and 2 hnsecs

[compiler dmd v2.067.0, Linux Ubuntu, 64bit]

import std.datetime : benchmark, Duration;
import std.string : format;
import std.conv : to;
import std.stdio : writeln;

enum {
   string[] words = ["Hello", "world", "Ola", "mundo"],

void main() {
   auto result = benchmark!(constLoop, refLoop, 
(Continue reading)

Chris via Digitalmars-d | 24 Apr 12:22 2015

Performance of map!()

I replaced a range that was similar to map with map and the 
performance dropped by ~0.5 msec.

The range I used previously is based on Adam's D Cookbook. It is 
consistently faster than map.

private struct Transformer(alias agent, R) if (isInputRange!R) {

   private R r;
   this (R r) {
     this.r = r;

   static if (isInfinite!R) {
     enum bool empty = false;
   else {
      <at> property bool empty() {
       return r.empty;

   void popFront() {

    <at> property ref auto front() {
     return agent(r.front);

(Continue reading)

Coding for solid state drives

An interesting article. Anyone want to see if there are any modifications we 
should make to std.stdio to work better with SSDs? (Such as changing the buffer 

Re: switch case expressions

On 4/23/15 5:04 PM, Jonathan M Davis via Digitalmars-d wrote:
> On Thursday, April 23, 2015 16:29:03 Steven Schveighoffer via Digitalmars-d wrote:
>> On 4/23/15 4:25 PM, bearophile wrote:
>>> Martin Krejcirik:
>>>> So, should the case b compile or not ? Is the spec too restrictive
>>>> here, or is it a bug ?
>>> Apparently it's a WONTFIX mess. The spec should be updated.
>>> Walter&Andrei refused to fix a design bug here.
>> Source?
>> IMO, the OP code does not warrant the errors cited.
> Well, there's this mess
> but I don't see anything in there from Walter or Andrei, so I'm not sure
> what Bearophile is referring to. Personally though, I wish that case
> statements only allowed compile-time constants... :|
> - Jonathan M Davis

Found it by following some references:

(Continue reading)