H1 2015 Priorities and Bare-Metal Programming

[H. S. Teoh via Digitalmars-d]

On Mon, Feb 02, 2015 at 09:53:43PM +0000, Dicebot via Digitalmars-d wrote:
> On Monday, 2 February 2015 at 21:19:05 UTC, Walter Bright wrote:
> >On 2/2/2015 9:17 AM, H. S. Teoh via Digitalmars-d wrote:
> >>Walter seems to dislike forced inlining for various reasons,
> >>preferring inlining as a hint at the most, and he probably has a
> >>point in most cases (let the compiler make the judgment). But in
> >>other cases, such as the one in question, the user needs to override
> >>the compiler's decision.  Currently there's no way to do that, and
> >>it's a showstopper for those users.
> >
> >This is a settled issue. After all, I wrote:
> >
> >http://wiki.dlang.org/DIP56
> 
> Erm. Quoting the DIP: "If a pragma specifies always inline, whether or
> not the target function(s) are actually inlined is implementation
> defined, although the implementation will be expected to inline it if
> practical."
> 
> This is exactly the absolutely unacceptable part that makes your DIP
> useless and last discussion has stalled (from my POV) exactly at the
> point where you refused to negotiate any compromises on that matter.

Yes, and this is the sore point with the force-inline proponents. You're
dangling the carrot of inline control in front of them, but snatch it
away with the "implementation-defined" part. That might as well not be
any control at all, since the default inlining behaviour is already
implementation-defined; having two states of implementation-defined
behaviour doesn't give us anything better than what we already have.

The whole point behind inline control is to give the programmer a way to
*override* the compiler's decision when the compiler's decision is
wrong. By saying it's implementation-defined, you put the decision back
in the compiler's hands, and so the compiler may continue making the
same wrong decision, and we have achieved nothing at all.

Of course, this is the pessimistic interpretation of DIP56, and perhaps,
as a bystander, I can hazard a guess as to why forced inlining is left
to the compiler's discretion -- one might want a compiler flag to
disable forced inlining for debugging purposes, for example. However,
without being more specific about exactly under what circumstances
forced inlining is not obeyed, DIP56 leaves the decision completely in
the implementor's hands, and users have no choice but to assume the
worst.


T

-- 
Notwithstanding the eloquent discontent that you have just respectfully expressed at length against my verbal capabilities, I am afraid that I must unfortunately bring it to your attention that I am, in fact, NOT verbose.