My thoughts & experiences with D so far, as a novice D coder

[Timon Gehr]

On 03/27/2013 05:04 PM, deadalnix wrote:
> On Wednesday, 27 March 2013 at 15:34:20 UTC, Vidar Wahlberg wrote:
>> ...
>
>> - While the "auto"-keyword often is great, it can lead to
>> difficulties, especially when used as the return type of a function,
>> such as "auto foo() { return bar; }". Sometimes you may wish to store
>> the result of a function/method call as a global variable/class
>> member, but when the function/method returns "auto" it's not apparent
>> what the data type may be. While you may be able to find out what
>> "bar" is by digging in the source code, it can still be difficult to
>> find. One example is to save the result of "std.regex.match()" as a
>> member in a class. For me the solution was to "import std.traits",
>> create a function "auto matchText(string text) { return match(text,
>> myRegex); }" and define the class member as "ReturnType!matchText
>> matchResult;" (do also note that function & member must come in the
>> right order for this to compile). This was all but obvious to a novice
>> D coder as myself, the solution was suggested to me in the IRC channel.
>>
>
> Yes, I have to say that it is a pain sometime. Additionally, it have
> some rough edges you may want to know :
>   - Function that never return are inferred void. I would have preferred
> typeof(null) as void lead to many static and repetitive code for nothing
> when doing metaprograming.

I strongly disagree. What would be an example of the problems you are 
apparently experiencing?

>   - Type inference handle very poorly recursion. It should simply
> exclude the recursion when doing type inference as it won't change the
> return type. The error message can be very opaque.

The cases that are allowed would need to be specified more rigorously.

>   - In some cases, you have to add explicit casts when implicit would
> have been enough in theory (but the type inference mechanism is confused).
>
> ...
>
>> - "Foo foo = new Foo();" for global variables/class members. Now you
>> must "Foo foo; static this() { foo = new Foo(); }".
>
> Yes, as it imply an heap allocation. It is an harder problem that it
> seems as all thoses object could reference themselves.

Just serialize the CTFE object graph into the static data segment.