<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2013/5/29 Manu <span dir="ltr"><<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div><div class="h5">Either way, the attribute certainly looks like it's part of the declaration, I think any reasoning programmer would assume that it is. It's only a DMD implementation detail that says otherwise, and it's not particularly intuitive to a programmer.<br>
</div></div>
</div>
</blockquote></div><br></div><div class="gmail_extra">It's not a dmd implementation detail. It is part of current D language design. dmd works as well. No bug there, so this is definitely an enhancement.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">But I can agree that is a little not good from human sense. I know a related issue.</div><div class="gmail_extra"><br></div><div class="gmail_extra">struct S {</div><div class="gmail_extra">
    immutable int foo() {}    // immutable is prefix attribute (==storage class)</div><div class="gmail_extra">}</div><div class="gmail_extra"><br></div><div class="gmail_extra">In above, `immutable` would be applied to the declaration `foo`, not its return type `int`.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">But, changing semantics would break much existing code. Your enhancement belongs same area. We need to get agreement of D programmers first.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">Kenji Hara</div></div>