H1 2015 Priorities and Bare-Metal Programming

[Andrei Alexandrescu via Digitalmars-d]

On 2/3/15 9:29 AM, Dicebot wrote:
> On Tuesday, 3 February 2015 at 08:31:24 UTC, Walter Bright wrote:
>> On 2/2/2015 8:36 PM, Daniel Murphy wrote:
>>> The user can modify the code to allow it to be inlined.  There are a
>>> huge number
>>> of constructs that cause dmd's inliner to completely give up. If a
>>> function
>>> _must_ be inlined, the compiler needs to give an error if it fails.
>>
>> A separate message with a pragmatic difficulty with your suggestion.
>>
>> Different compilers will have different inlining capabilities.
>> Different versions of the same compiler may behave differently. This
>> means that sometimes a user may get a compilation failure, sometimes
>> not. It's highly brittle.
>
> This is _exactly_ why error message is needed.

I think the best route here - and the most in-the-spirit-of-D - is to 
provide introspection on whether a function is being inlined or not. 
Then we can always have in libraries:

bool uart(ubyte b)
{
     static assert(__traits(inlined),
       "Inlining of uart() must be supported.");
     ...
}


Andrei