IMO, the fact that pure function pointers don't implicitly cast to non-pure ones with equivalent args is a separate problem. Same for @safe and nothrow.
-Steve Sent from my iPhone On Nov 18, 2011, at 3:04 AM, Don Clugston <[email protected]> wrote: > On 18 November 2011 04:48, Steve Schveighoffer <[email protected]> wrote: >> >> >>> ________________________________ >>> From: Don Clugston <[email protected]> >>> >>> >>> No, I'm worried about noisy breaking of pure/nothrow. It can even go >>> in the other direction. Delete a read from a static variable in the >>> body of a template function (not the signature) and now your code >>> won't link, because the function suddenly became pure. The issue is >>> predictability. >>> >> >> >> First, templates do *not* do well as stale objects or dynamically linked >> ones (this is from experience with C++). I remember we had this great idea >> that we would standardize on std::string for a lot of things in a library at >> work, where things were dynamically linked. One upgrade to libstdc++, and >> bizarro errors start occurring. We eventually used stlport where we could >> control the string implementation to avoid surprises. > > It affects more than templates. > >> Second, you *want* the linking to fail if the object is stale. What if >> purity or nothrow is *removed* by a change to a function? > > That direction is fine. The idea behind the current implementation is, > that if you don't have the source code to the function, then you > _cannot_ rely on implicit purity. You only have purity if it's > explicitly written in the source code. > > Does the current implementation actually work? Kenji's example is a > pretty strong argument that it doesn't. But that's the idea behind it. > >> Bottom line, I don't think changing the signature of a function, whether >> implied or not, and not recompiling dependent code is a valid use case, or >> at least one we should care about. > > The thing is, it includes code which wasn't dependent prior to the > introduction of implied purity. For example, function pointers with > implicit type deduction. External code doesn't need to be able to see > the initializer, it only needs to know the type. Currently, > automatically generated di files always include the initializers, and > don't put in the deduced type. There'd be a huge speed increase if the > initializers were dropped. But we're introducing cases where function > bodies must be included, solely for type deduction. > > This statement from Kenji is quite plausible: >> But, conservative mangling of template function never rescue anything, IMO. >> It just decrease the type information and cause inconsistent confusion. > > I fear that this is right. _______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
