Documentation: is it intentional that template constraints are displayed after the signature?

[Jonathan M Davis]

On Friday, November 1, 2019 11:23:42 AM MDT Ali Çehreli via Digitalmars-d-
learn wrote:
> On 11/01/2019 09:33 AM, Paul Backus wrote:
>  > On Friday, 1 November 2019 at 15:29:24 UTC, Ali Çehreli wrote:
>  >> Apparently, it's the version for static arrays. However, I don't think
>  >> the template constraint is doing anything there because if T matches a
>  >> static array (of the form U[n]), then T is not a struct anyway.
>  >>
>  >> Ali
>  >
>  > `T : U[n]` could also be matched by a struct with an `alias this` to a
>  > static array member.
>  >
>  > Example: https://run.dlang.io/is/NgRU94
>
> Thanks. Is it special to destroy() to care for that case or should all
> our algorithms be on the watchout for such structs? I'm sure I would be
> missing that specialization if I ever needed to write similar
> specializations for an algorithm.

Pretty much any time that a template constraint uses an implicit conversion,
the code needs to be careful. Typically, the code then needs to force the
conversion and then operate on the exact type in order to avoid subtle bugs.
Honestly, in general, I'd argue that it's better to just not accept implicit
conversions with templates.

In this particular case, what it should probably be doing is just use
__traits(isStaticArray, ...) in the template constraint, but whoever wrote
that overload took a different tact (though depending on how old that trait
is and how old that overload of destroy is, the trait may or may not have
been an option when that overload of destroy was written).

- Jonathan M Davis