<div class="gmail_quote">On 6 April 2012 17:53, Timon Gehr <span dir="ltr"><<a href="mailto:timon.gehr@gmx.ch">timon.gehr@gmx.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 04/06/2012 04:23 PM, Steven Schveighoffer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why should we be restricted to only structs? Or any type for that matter?<br>
<br>
</blockquote>
<br></div>
A restriction to only structs is not a restriction because structs can have arbitrary field types.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The benefit to using CTFE functions is that the compiler already knows<br>
how to deal with them at compile-time. i.e. less work to make the<br>
compiler implement this.<br>
<br>
</blockquote>
<br></div>
It is exactly the same amount of work because CTFE is able to execute struct constructors.<br>
</blockquote></div><br><div>The only real difference I see, is at the end of the day, the one level of indirection (the function call) allows you to create an attribute with a different name than struct that defines it. Otherwise they would seem to be functionally equivalent.</div>
<div>Chances are, the creator function would just execute the struct's constructor internally anyway. But maybe the function approach has an effect on the simplicity of the expression for a simple attribute, like a single bool?</div>
<div>I suppose a single bool attribute wouldn't work so well declared the constructor way, it really does need the name it would inherit from the creator function...</div>