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.
