Consistency, Templates, Constructors, and D3

[Nick Treleaven]

On 25/08/2012 07:45, David Piepgrass wrote:
> 2. immutable int[] func()... does not return an immutable array of int[]?

Maybe this should be disallowed with an error message "prefix immutable 
is deprecated - either use suffix immutable or immutable(int[])":

http://d.puremagic.com/issues/show_bug.cgi?id=4070

Unfortunately that is marked WONTFIX.

> Making matters worse, the language itself and most of its constructs are
> non-Googlable. For example if you don't remember how do declare the
> forwarding operator (alias this), what do you search for? If you see
> "alias _suchAndSuch this" and don't know what it means, what do you
> search for? (one might not think of removing the middle word and
> searching for that).

alias syntax is confusing and inconsistent with renamed imports. It 
should use assignment syntax:

alias Bar = expression;
alias this = foo;

http://d.puremagic.com/issues/show_bug.cgi?id=3011

> Interestingly, the discussion so far has been all about syntax, not any
> significant new features. I'm thinking ... coersion of a class to any
> compatible interface (as in Go)?

We already have:

import std.range;
auto range = ...;
auto obj = inputRangeObject(range);
alias ElementType!(typeof(range)) E;
InputRange!E iface = obj;
writeln(iface.front);

So maybe we can do:

auto implementObject(Interface, T)(T t){...}
auto obj = implementObject!(InputRange!E)(range);

Also, it might be nice to have 'canImplement' for template constraints:

auto foo(T)(T v) if (canImplement!(T, SomeInterface)){...}

Nick