On 2015-07-22 20:47, simendsjo wrote:
Traits
------
I think the ability to express an interface without buying into
inheritance is the right move. The alternative in D is specifying the
behavior as a template and verifying the contract in a unittest for the
type.
I completely agree and don't really like the approach D has implemented
template constraints. Yeah I know, Andrei will destroy this :)
Macros
------
I haven't written more than extremely simple macros in Rust, but having
macros that is possible for tools to understand is a win. Templates and
string mixins is often used for this purpose, but trying to build tools
when string mixins exists is probably extremely hard. If D had hygenic
macros, I expect several features could be expressed with this instead
of string mixins, making tooling easier to implement.
I completely agree. String mixins are one of the most ugliest features.
Safe by default
---------------
D is often said being safe by default, but D still has default nullable
references and mutable by default. I don't see it being possible to
change at this stage, but expressing when I want to be unsafe rather
than the opposite is very nice. I end up typing a lot more in D than
Rust because of this.
Agree.
Pattern matching
----------------
Ooooh... I don't know what to say.. D should definitely look into
implementing some pattern matching! final switch is good for making sure
all values are handled, but deconstructing is just so ergonomic.
Yeah, pattern matching is soooo nice. I've been trying to implement
something similar in D as a library, something like this:
auto foo = Foo();
match!(foo
Foo, (int a, int b) => writeln(a, b);
);
Which kind of works for deconstructing variable pattern. But then you
want to have a pattern where "a" is 1, they it becomes much harder:
match!(foo
Foo, (value!(1), int b) => writeln(b);
);
Or
match!(foo
Foo, 1, (int b) => writeln(b);
);
But now you need to use different syntax for value pattern and variable
pattern and soon everything becomes a big mess.
It will never be as good as proper language support.
Expressions
-----------
This probably also falls in the "too late" category, but
statements-as-expressions is really nice. `auto a = if ...` <- why not?
I really like, I use it a lot in Scala. The with the combination of
automatically return the last thing in a method and methods not needing
curly braces for single expression methods is really nice:
def foo(a: String) =
if (a == "foo")
1
else if (a == "bar")
2
else
3
On the breaking part, the
real issue is the "We're not going to break any code!" stance, while
each release still breaks every codebase. The effect is that a lot of
really long-term necessary breaking changes is never accepted - the only
breaking changes is the unintended breaking changes!
Agree.
--
/Jacob Carlborg
