<div dir="ltr"><div>I just wanted to share a brief discussion on a PR last night, because it's something that's always bugged me, and there is a change in 2.111 that tightens the rules for declaring auto ref such that the keywords must appear next to eachother.</div><div><br></div><div>In the PR there was a piece of code that went `const auto ref T`, and I suggested changing to `auto ref const T` as convention at least.<br></div><div><br></div><div>The reason I perceive is that this is valid syntax: <code class="gmail-notranslate">auto ref const(CowArray) rhs</code><br></div><div>This is not: <code class="gmail-notranslate">const(auto ref CowArray) nhs</code></div><div><br></div><div>
For me, it's a conceptual flow thing:<br>
<code class="gmail-notranslate">const auto ref T</code> goes: type stuff (<code class="gmail-notranslate">const</code>) -> storage class stuff (<code class="gmail-notranslate">auto ref</code>) -> type stuff (<code class="gmail-notranslate">T</code>)<br>
<code class="gmail-notranslate">auto ref const T</code> goes: storage class stuff (<code class="gmail-notranslate">auto ref</code>) -> type stuff (<code class="gmail-notranslate">const T</code>)<br></div><div><br></div><div>
It feels crude to interleave type stuff and storage class stuff in an arbitrary way.

</div><div><div><span disabled><p dir="auto">The distinction feels more compelling when you consider that parens may appear after type constructors (<span style="font-family:monospace">const(T)</span>), and so in those cases, the code MUST be written with the const immediately preceding the type, forcing the storage class to the left.<br></p></span></div></div><div><span disabled><div class="gmail-comment-body gmail-markdown-body gmail-js-comment-body gmail-soft-wrap gmail-css-overflow-wrap-anywhere gmail-user-select-contain gmail-d-block"><p dir="auto">
Since it's invalid to put storage class stuff on the end (actual type 
must be on the end), then I would mandate that storage class stuff 
should go at the start, not randomly in the middle somewhere, ie: storage_class type_constructor actual_type</p><p>If it were up to me, I would mandate this in the spec, but failing that, at least proliferate this by general policy; I think this helps non-D coders to osmose this complexity without a detailed conversation... and for everyone else, the code just reads more consistently.</p><p>I see a surprising number of people writing `const ref T`, and I suspect that people are writing it holding the same kind of conceptual confusion that a lot of new users have expressed to me. As I see it, the fact people tend to write this at all is clear evidence that we shouldn't allow it!<br></p><p><br></p><p>Similarly, allowing attributes on functions should likewise appear after the function prototype:</p><p>
</p><pre class="gmail-notranslate"><code class="gmail-notranslate">struct S {
  const(T) method();
  const T method(); // not the same; synonym for `T method() const`
}</code></pre>


    </div><div class="gmail-comment-body gmail-markdown-body gmail-js-comment-body gmail-soft-wrap gmail-css-overflow-wrap-anywhere gmail-user-select-contain gmail-d-block">This kind of confusion is just totally unnecessary. Any non-expert reader would assume they are the same. There's no value in inviting this confusion.</div>
  </span>

</div></div>