bearophile wrote in message news:rrtewrwyiuhmkvmhf...@forum.dlang.org...
Seems like something that would fit in well with dscanner.
Nope. It's not a bug for the programmer, it's an optimization pass for the
compiler. And it should work after inlining.
It's not a programmer bug, but that
bearophile wrote in message news:tgxtiqcfxfhpmubfk...@forum.dlang.org...
But perhaps the same is possible and useful in D too.
http://forum.dlang.org/thread/qeytzeqnygxpocywy...@forum.dlang.org
On Saturday, 20 December 2014 at 14:16:05 UTC, bearophile wrote:
When you use UFCS chains there are many coding patterns that
probably are hard to catch for the compiler, but are easy to
optimize very quickly:
[cut]
.reverse.reverse = id
.reverse.reverse is a coding pattern??
;-)
renoX
renoX:
.reverse.reverse is a coding pattern??
Yes, similar patterns can come out after inlining.
Bye,
bearophile
When you use UFCS chains there are many coding patterns that
probably are hard to catch for the compiler, but are easy to
optimize very quickly:
.sort().group.canFind = binary search
.sort().front = .reduce!min
.reverse.reverse = id
.reverse.back = .front
If the filtering and mapping
On Saturday, 20 December 2014 at 14:16:05 UTC, bearophile wrote:
If the filtering and mapping functions are pure nothrow:
.map.filter = .filter.map
I think that one doesn't work.
Seems like something that would fit in well with dscanner.
weaselcat:
Seems like something that would fit in well with dscanner.
Nope. It's not a bug for the programmer, it's an optimization
pass for the compiler. And it should work after inlining.
Bye,
bearophile
On Saturday, 20 December 2014 at 14:16:05 UTC, bearophile wrote:
In Haskell this is so common that GHC has a feature named
rewrite rules:
Pure is fully based on term rewriting:
http://purelang.bitbucket.org/