https://issues.dlang.org/show_bug.cgi?id=22596
--- Comment #5 from Andrei Alexandrescu <[email protected]> --- (In reply to moonlightsentinel from comment #4) > (In reply to Andrei Alexandrescu from comment #3) > > The symbol is not undefined because the documentation is nested inside the > > `canon` template, which is parameterized on v. > > On a different page, not defined alongside the example. > > Also ignores the fact that a documented unittests contributes an executable! > example (backed by run.dlang.io) to the offical documentation. Accepting > such tests would mean that examples would be broken unless modified by the > user. Allow me to repeat to make sure I understand correctly: no documentation unittest nested inside a template in phobos could ever access the template parameters. The reason is that those unittests are transformed into runnable examples on the website, which are at the top level (hence have no access to the enclosing template's arguments). That makes sense, I assume it's documented somewhere. However I see it more of a limitation of the way we go about runnable unittests than a "nothing to be seen here" situation. > > Does this work properly with `make publictests`? > > No, it would fail as expected. The definition / value of `v` is unknown to > the user who run this example on the website / in his code. > > ------ > > Such tests should probably provide a declaration of `v` with a default > value. This could probably be realized via tooling s.t. phobos can test > different versions while the website examples include an explicit `enum v = > "..."`. Well the problem is a tad deeper. The tests need to be run for all versions of the standard, that's the whole point of putting them in there. Having them check all versions of the standard is great leverage. That we can't do that is a serious issue. Let's leave this open in search for a good solution. --
