On Monday, 4 January 2016 at 07:55:53 UTC, Jacob Carlborg wrote:
On 2016-01-02 21:47, Chris Wright wrote:
So you want to create the following query:
people.filter!(x => x.surname == "Slughorn");
And you've got ten million people in the collection, and you
want this
query to finish soonish. So you need to use an index. But a
full index
scan isn't so great; you want to do an index lookup if
possible.
That's simple enough; we generate proxy types to record what
properties
you're using and what operations you're performing.
PersonProxy records
that you're accessing a field 'surname', gives a
StringFieldProxy, and
that records that you're checking for equality with the string
"Slughorn".
The lambda returns true when opEquals returns true.
But people write queries that are more complex than that, like:
people.filter!(x => x.surname == "Slughorn" || x.age <= 17);
First time you run this, x.surname.opEquals("Slughorn")
returns true and
the expression as a whole returns true. You missed the second
part of the
expression. That's bad.
If D had better operator overloading or supported AST macros,
opEquals would not return true. It would return a new proxy
that overloads the || operator. The rest of the post falls
apart from this mistake.
compiler plugins like Rust to enable AST macros could fix this
but walter and andrei seem extremely opposed to any form of
macros so we end up with ugly heavily templated ugly band-aids
shame, because I think D will quickly lose their lead in the
metaprogramming area if Rust keeps it up - e.g, someone already
made a GC Plugin for rust's compiler
