[dmd-internals] Type mangling for deduced attributes

Steve Schveighoffer schveiguy at yahoo.com
Thu Nov 17 19:48:22 PST 2011



>________________________________
>From: Don Clugston <dclugston at googlemail.com>
>
>
>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.


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?

For example, you have in your library:

char foo(uint n)(in char[] s) // implicitly pure

{
   return s[n];

}

void bar()
{
   foo!3("hello");

}

Now, in a separate program, that is dynamically linked with your lib, you have:

pure int baz()
{
   return foo!3("gobble") + 5;

}

OK.  So now, you change your library's foo to this:

char foo(uint n)(in char[] s)
{
   return cast(char)(s[n] + rand()); // oops, rand makes it no-longer pure.

}

Since bar instantiates foo!3, it gets stored in the lib.  Updating the lib but not recompiling the app results in code that runs, but is likely wrong.  I'd rather have it fail to dynamically load because of a missing symbol.

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.

-Steve



More information about the dmd-internals mailing list