This Week in D July 19, 2015

Welcome to This Week in D! Each week, we'll summarize what's been going on in the D community and write brief advice columns to help you get the most out of the D Programming Language.

The D Programming Language is a general purpose programming language that offers modern convenience, modeling power, and native efficiency with a familiar C-style syntax.

This Week in D has an RSS feed.

This Week in D is edited by Adam D. Ruppe. Contact me with any questions, comments, or contributions.


Open D Jobs

A page has been added to the D Wiki listing open D jobs. Take a look if you're interested, and add yours if you know of one that is available!

In the community

Community announcements

See more at digitalmars.D.announce.

Significant Forum Discussions

Creator of LLVM, Clang, and Swift Says To Not Write Security Critical Code In C/C++ was a thread mostly about performance optimizations and the importance of profiling.

The other main discussion was the AliasSeq bikeshedding, continued from last week. The decision that was merged into Phobos was to just stay with AliasSeq.

Tip of the Week

This week, I was asked a question about alias this and constructors. I will reproduce my answer here as it may be of general interest: just how does alias this work? What is the rule on constructing structs inside classes?

Is there any reason why implicit conversion from Foo to Thing is permitted in a regular method but not in a constructor?

In the constructor, you are supposed to be constructing things, so the first "assignment" of structs is actually a constructor call. D does not support implicit construction (kinda sadly, but it doesn't).

In the other methods, it calls opAssign instead, since the struct already exists. So this is the difference between:

Thing thing = new Foo(); // in the ctor, this line in main wouldn't work either with the same error

// and

thing = new Foo(); // in the other method, this line in main does work

Try adding void opAssign(T)(T t) { static assert(0); } to your struct and recompile. You'll see it throws on the method. Then change that opAssign to this, so it becomes a constructor. Then you'll see it is called in the class constructor.

Moreover, note that this only applies to the *first* assignment of the struct. If you copy/paste that line in the constructor again right under it, you'll see the compiler only throws the error once. The first one is a construction. The second one is a standard assignment again.

Put those two lines in a runtime branch: if(something) thing = new Foo(); else thing = new Foo(); and notice how the compiler throws two errors again.

The first assignment in any branch of a constructor is a construction! The next one is an assignment.

So the rule is slightly complex (and the implementation may be buggy, though it seems good to me now), but it is intentional.

The reason for this goes beyond just that constructors are supposed to be constructing. It also is relevant for immutable members - these are allowed to be constructed, but not modified, so if the class constructor didn't treat those as constructions, it would be impossible to set them up with runtime data.

And it is also important for @disable this() struct members, which must be constructed explicitly. If the first assignment in a ctor didn't count for that, you couldn't have them in a class at all.

How does alias this work anyway?


struct Foo {
   T x;
   alias x this;

Any time you do

Foo foo;

foo.something = whatever;
// or
foo = whatever;
// or
whatever = foo;

It first tries that code directly. If that doesn't work, it then tries rewriting foo into foo.x:

foo.x.something = whatever;
foo.x = whatever;
whatever = foo.x;

And if that compiles, you're all set, that code gets generated.

The OP's situation is just case #2 here. The compiler is taking the illegal thing = new Foo; and rewriting it into the legal = new Foo; automatically via alias this.

Learn more about D

To learn more about D and what's happening in D: