Florian

Some (possible) minor advantages(?): 1. Removes a redundant custom type 2. `only()` can be used to initialize other types that accept a slice 2. `front` and friends become `noreturn` as...

True, relying on that behavior would be problematic when `only` is used in variadic templates

FYI the current implementation breaks the navigation in the documentation, see e.g. [std.algorithm](http://dtest.dlang.io/artifact/website-4c001ba3372ccfc7bf57e55d666d5a39e5c03c08-43b223646ebfae283b758a11c877fdf8/web/library-prerelease/std/algorithm.html) and [std.algorithm.searching](http://dtest.dlang.io/artifact/website-4c001ba3372ccfc7bf57e55d666d5a39e5c03c08-43b223646ebfae283b758a11c877fdf8/web/library-prerelease/std/algorithm/comparison.html)

Good. But it's a red flag that an implementation detail like `canon` leaks into the documentation at all.

> Not that I'm an expert, but out of curiosity why does the code pass "auto-tester" tests for "Darwin_64_32" but not for the other configurations? Is there a machine dependence...

> I see there are some mangling tests I can look up but they don't seem to test invisible/auto-generated symbols so I need a bit of guidance on how to...

Well, this breaks a lot of projects on BuildKite (and even more unchecked projects) - mostly due to the "redundant" `in ref`. I think it would be better to change...

> * We usually don't deprecate in the parser, because it would mean `static if` and `version` are not affected and the deprecation would show unless in a mixin; Agreed...

> Well it does affect tools that do parsing only. And it was made to be consistent with the other STCs. > I actually tried to move it to semantic...

Restarted the failures but the segfault in `libmir/mir-algorithm` might not be unrelated.