DMD 0.170 release

[Lars Ivar Igesund]

Walter, you always say that new features shouldn't be added if they fairly
easily can be done with existing language constructs. Now, the post below
is about possible new features in D (of general interest and with many
possible applications), and it is shown how they can be used to implement
an existing (and specific) feature in D. I'm not sure if this should be
used as an argument for removing the new delegate-as-aggregate feature, but
it certainly shows that the proposed features have merit.


Tom S wrote:

> Walter Bright wrote:
>> Added foreach_reverse, which addresses a serious shortcoming.
>> 
>> http://www.digitalmars.com/d/changelog.html
> 
> Thanks for the new release :)
> 
> The foreach-on-delegate seems like a great feature, but in a somewhat
> harder to implement shape, it has been available for quite a while:
> 
> ----
> 
> import std.stdio;
> 
> 
> template opHackedApply(alias theImplFunc, IterType) {
> Iter entry() {
> Iter it; it.impl = &theImplFunc; return it;
> }
> struct Iter {
> int delegate(IterType) impl;
> int opApply(IterType dg) {
> return impl(dg);
> }
> }
> }
> 
> 
> class Foo {
> int oldIterImpl(int delegate(inout int) dg) {
> int a;
> a = 3; dg(a);
> a = 9; dg(a);
> return 0;
> }
> mixin opHackedApply!(oldIterImpl, int delegate(inout int)) oldIterMix;
> alias oldIterMix.entry oldIter;
> }
> 
> 
> void main() {
> Foo f = new Foo;
> 
> foreach (i; f.oldIter) {
> writefln(i);
> }
> }
> 
> ----
> 
> Sure it doesn't look as nice, but at least it doesn't require the '&'
> token... But the point is that delegates don't have to be considered
> aggregates in order to implement this feature. Let's now assume that we
> have a few other features in D:
> 
> 1. tuples
> 2. better metainfo for delegates and functions
> 3. hiding of private template members (so they dont interfere with
> automatic name promotion)
> 4. automatic name promotion of mixins:
> 
> template foo() {
> void foo() {}
> }
> 
> struct Bar {
> mixin foo myFunc;
> void otherFunc() {
> myFunc();     // currently requires `myFunc.foo();`
> }
> }
> 
> 
> Then the hacked opApply can be used like:
> 
> ----
> template opHackedApply(alias theImplFunc) {
> Iter opHackedApply() {
> Iter it; it.impl = &theImplFunc; return it;
> }
> 
> private alias theImplFunc.paramTypesTuple;
> private struct Iter {
> int delegate(IterType) impl;
> int opApply(IterType dg) {
> return impl(dg);
> }
> }
> }
> 
> class Foo {
> int oldIterImpl(int delegate(inout int) dg) {
> int a;
> a = 3; dg(a);
> a = 9; dg(a);
> return 0;
> }
> mixin opHackedApply!(oldIterImpl) oldIter;
> }
> ----
> 
> It's not as short as the treatment-of-delegates-as-aggregates but it
> only uses builtin features. Yeah, builtin features of my dreamed D
> version, but all the required features have been proposed before and
> would make the whole language better (IMHO, but I'm sure more people
> would agree with me here). On the other side, allowing iteration on
> delegates only because they match a required signature doesn't make the
> language simpler at all.
> 
> 
> --
> Tomasz Stachowiak

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi