<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2013/12/19 Timon Gehr <span dir="ltr"><<a href="mailto:timon.gehr@gmx.ch" target="_blank">timon.gehr@gmx.ch</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">The natural interpretation of a const constructor is that it constructs a const object directly. Such a constructor could eg. initialize a field declared with a mutable type using some external const reference.<br>
</div>
<br>
void foo(const(int[]) a){<br>
    // ...<br>
    struct S{<br>
        int[] a;<br>
        this()const{<br>
            this.a=a;<br>
        }<br>
    }<br>
    // ...<br>
}<br>
<br>
The DIP argues that such a construct is not particularly useful </blockquote><div><br></div><div>Yes, that's one of the start point of my thoughts. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and hence eliminates it for the purpose of using the syntax for a _different_ concept. There is no way to implement the above constructor using the new semantics.<br>
</blockquote></div><br></div><div class="gmail_extra">No, that's not merely syntactic choice. The 'const' constructor/postblit is a natural conclusion derived from the semantic meaning.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">I tweaked descriptions in DIP to express it more clearly.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Kenji Hara</div></div>