Why the @ in @safe? & UDAs

[Timon Gehr]

On 11/10/2013 08:45 PM, John Colvin wrote:
> On Sunday, 10 November 2013 at 19:24:53 UTC, Andrei Alexandrescu wrote:
>> On 11/10/13 11:14 AM, Timon Gehr wrote:
>>> On 11/10/2013 05:39 PM, Andrei Alexandrescu wrote:
>>>> On 11/9/13 1:27 AM, SomeDude wrote:
>>>>> I would add that constant breaking changes make the language unfit for
>>>>> industrial usage in the long term.
>>>>> Let's remember that D is being pushed in production by Andrei at
>>>>> Facebook. If the language breaks everything at each release, there
>>>>> is no
>>>>> way Facebook or any other company for that matter is going to bet a
>>>>> dime
>>>>> on it.
>>>>
>>>> Agreed with qualifications. We at Facebook are well aware that bumping
>>>> the gcc release will inevitably cause breakages, and are able and
>>>> willing to put up with them for the sake of the benefits. This of
>>>> course
>>>> is guided by the breakage/benefits ratio.
>>>>
>>>> Andrei
>>>>
>>>
>>> What about just shipping a fully automated fix-up tool when trivial but
>>> major breaking changes happen?
>>
>> That's nice because in a good way it puts the onus on the breakers.
>> For it to be useful, the tool would have to be rock solid and work in
>> 100% cases.
>>
>> Andrei
>
> string mixins?

Just let CTFE thread through additional state describing the locations 
of the constant literals the code is assembled from, and make sure the 
fix-ups do not influence anything else. For the off chance that some 
part of the generated code that we want to change is actually computed 
from other data, it is still possible to require manual interaction, but 
I don't know of any real code for which this might be the case.

Code relying on stringof, eg. stringof returning '@safe' in types 
instead of 'safe' would be quite hard to handle as well, but it should 
still be possible to handle the relevant subset of cases.

Of course, such a tool would be quite a piece of engineering. :o)