Ah, simple solution to unittests inside templates

[Andrei Alexandrescu via Digitalmars-d]

On 09/18/2016 04:29 PM, Jonathan M Davis via Digitalmars-d wrote:
> On Sunday, September 18, 2016 08:14:47 Andrei Alexandrescu via Digitalmars-d
> wrote:
>> On 9/18/16 6:00 AM, Jonathan M Davis via Digitalmars-d wrote:
>>> Yes. That's DIP 82:
>>>
>>> http://wiki.dlang.org/DIP82
>>>
>>> I need to go over it again and then introduce it into the new DIP process.
>>> But I really think that that's where we should go to fix this problem.
>>
>> Just a thought: things that we can't do have high priority. Things that
>> we can do with a modest cost are much less attractive. Consider:
>
> Is this the biggest issue we have? No. But that doesn't mean that it isn't
> important and that it shouldn't be addressed. It just means that it's not
> the highest priority and therefore probably not what happens next. But also
> consider that implementing this is probably straightforward enough that
> someone other than Walter could implement it, and it wouldn't necessarily
> have to take away from something more critical like DIP1000. Aside from
> approval, I wouldn't expect that this would require Walter. If it were
> approved by Walter sometime in the nearish future, then after that, it could
> be implemented by any of the compiler devs whenever they could fit it in,
> whether that's sooner or later. I'm fairly certain that in this case, the
> main problem is the approval and not the implementation.
>
> I fully intend to update the DIP for this and submit it for approval with
> the new process. If that needs to wait for some reason, then that's not the
> end of the world. But I definitely think that this is a problem that we
> should solve and not just write off because we have an ugly workaround.

Understood. I don't want anyone to get furious later on account of my 
sugarcoating things, so let me say this: I'm likely to oppose such a 
proposal. Walter and I have similar design sensibilities so he's likely 
to oppose it too. I don't think this is an important issue that should 
be addressed. The ease of implementation argument is, as discussed 
before, fallacious. What you call an ugly workaround I call business as 
usual using the nice facilities of the D language. I suggest you work on 
ideas with more impact. -- Andrei