This is only true for instantiations that aren't invoked in the std lib. Any future instantiations that match ones in the std lib will use the version compiled into Phobos. It makes for very inconsistent results. I personally think that until enforce doesn't prevent inlining it should not be used anywhere in ranges since much of the range concept's charter is for inlining performance advantages.
Sent from my iPhone On Aug 18, 2010, at 7:36 PM, David Simcha <[email protected]> wrote: > A valid criticism in general. However, all of the ranges in question are > templates, so each instantiation is compiled in whatever mode your program is > compiled in. > > On 8/18/2010 7:08 PM, Jonathan M Davis wrote: >> The ideal situation would be to use asserts in all cases where it's going to >> be >> bugs in the program rather than bad user input and that they go away in >> release >> mode. The problem is the fact that Phobos is compiled as an external library >> rather than being compiled in with your code when you compile. And since >> there's >> no way (at least no standard way) to have a release and debug version of the >> Phobos libraries, with the release version being used in release mode and the >> debug version being used in debug mode, that pretty much means that you >> _always_ >> compile your code with the release version of Phobos. This makes assert >> _useless_ for users of the library. If you want checks beyond within Phobos >> code, you _have_ to use enforce(), and since enforce has issues with inlining >> and it doesn't go away in release mode, it's like forcing a portion of Phobos >> into debug mode. >> >> _Ideally_, we would find some sort of standard way to make Phobos used in >> debug >> mode when compiling in debug mode and release mode when compiling in release >> mode. That way, asserts could be used in a lot of these cases since a lot of >> them really shouldn't be checked in release mode. Personally, I _really_ >> don't >> like the fact that the libraries aren't necessarily in the same mode as your >> code, though I'm not sure that there's a good way to deal with that other >> than >> having some standard naming scheme for debug vs release libraries which >> Phobos >> uses and dmd understands so that you get a debug version when compiling your >> code in debug mode, and you get a release version when compiling in release >> mode. Barring that however... >> >> You'd almost have to take it on a case by case basis. In some cases, you're >> going to need checks and it would be bad not to have them, while in others, >> it >> would just cost too much to leave them in. It's a tough call. If anything >> though, I think that it's a prime example of needing to find a better way to >> deal >> with debug vs release and libraries. If we had a standard way to have both >> available, then dmd could use both with user code, and then we can use >> asserts >> like they should be used. As it stands though, we're probably going to have >> to >> use enforce() where we _need_ checks for safety and asserts otherwise. But >> since >> using asserts is almost pointless.... Bleh. It's just ugly. >> >> - Jonathan M Davis >> _______________________________________________ >> phobos mailing list >> [email protected] >> http://lists.puremagic.com/mailman/listinfo/phobos >> >> > > _______________________________________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
