__traits(compileError, {})

[bitwise via Digitalmars-d]

On Monday, 11 September 2017 at 00:15:08 UTC, Jonathan M Davis 
wrote:
> On Sunday, September 10, 2017 23:25:59 bitwise via 
> Digitalmars-d wrote:
>> On Friday, 8 September 2017 at 01:18:46 UTC, bitwise wrote:
>> > [...]
>>
>> Does anyone even follow procedures of any kind for additions 
>> this trivial, or do they just do pull requests and debate it 
>> there?
>
> Additions to the standard library on the size of new modules or 
> redesigned modules require a formal review in the main 
> newsgroup, but making changes to individual functions don't. If 
> you're looking to add something to the compiler, it could 
> simply be a PR, or it could require a DIP, depending on its 
> scope and what Walter and the other compiler devs think.

Ok, makes sense - Thanks. My own learning curve aside though, it 
doesn't seem prohibitively time consuming to just try this myself 
at some point.

> In the case of your suggestion, I'd argue that it would simply 
> be better to improve the compiler-generated error messages if 
> they're not good enough.

I'm suggesting the opposite. I'm saying that the compiler 
messages _are_ good enough, but that some functions in phobos 
(emplace, for example) suppress them by using code like this:

`
static if(__traits(compiles, { ... }))
     doIt();
else
     static assert("custom error message");
`

So instead of a custom error message, you could simply run the 
offending code through the compiler and output what it says. The 
compiler's error message would most likely be much better and 
more detailed than the custom one inserted by hand.

So essentially, the above would be refactored like this:

`
static if(__traits(compiles, { doIt(); }))
     doIt();
else
     static assert("Failed to invoke 'doIt': \n\t" ~ 
__traits(compilerError, { doIt(); }));
`

For the case of emplace() though, I'm wondering if that static if 
even needs to be there at all - maybe not.