Re: D idioms list

[Artur Skawina via Digitalmars-d-announce]

On 01/08/15 21:23, ketmar via Digitalmars-d-announce wrote:
 i'm not sure, but maybe it worth renaming struct inheritance to
 extending a struct? or even something completely different. what it
 does is actually extending/augmenting the struct, but not
 OO-inheritance, as one cannot pass augmented struct to the function
 which expects original struct. at least without hackery.

'alias this' is just the D syntax for implicit conversions.
The feature /is/ crippled, but there's no need for hackery;
at least not for simple things like that.

   struct A { int a; }
   struct B { A a; alias a this; string b; }

   int f(A a) { return a.a+1; }
   int g(ref A a) { return a.a+1; }
   ref A h(ref A a) { return a; }

   int main() {
  B b;
  return f(b)+g(b)+h(b).a;
   }

artur

Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky

[Artur Skawina via Digitalmars-d-announce]

On 06/12/14 11:17, Dmitry Olshansky via Digitalmars-d-announce wrote:
 This one thing I'm loosing sleep over - what precisely is so good in CTFE 
 code generation in _practical_ context (DSL that is quite stable, not just 
 tiny helpers)?

Language integration; direct access to meta data (such as types, but
also constants).

 By the end of day it's just about having to write a trivial line in your 
 favorite build system (NOT make) vs having to wait for a couple of minutes 
 each build hoping the compiler won't hit your system's memory limits.

If it really was only about an extra makefile rule then CTFE wouldn't
make much difference; it would just be an explicitly-requested smarter
version of constant folding. But that is not the case.

Simple example: create a function that implements an algorithm
which is derived from some type given to it as input. /Derived/
does not mean that it only contains some conditionally executed
code that depends on some property of that type; it means that
the algorithm itself is determined from the type. With the
external-generator solution you can emit a templated function,
but what you can *not* do is emit code based on meta-data or
CT introspection - because the necessary data simply isn't
available when the external generator runs.
With CTFE you have direct access to all the data and generating
the code becomes almost trivial. It makes a night-and-day type of
difference.
While you could implement a sufficiently-smart-generator that could
handle some subset of the functionality of CTFE, it would be
prohibitively expensive to do so, wouldn't scale and would often be
pointless, if you had to resort to generating code containing mixin
expressions anyway. There's a reason why this isn't done in other
languages that don't have CTFE.

 Unless things improve dramatically CTFE code generation + mixin is just our 
 funny painful toy.

The code snippets posted here are of course just toy programs.
This does not mean that CTFE and mixins are merely toys, they
enable writing code in ways that just isn't practically possible
in other languages. The fact that there isn't much such publicly
available code is just a function of D's microscopic user base.

Real Programmers write mixins that write mixins.

artur