"Walter Bright" wrote in message news:maq10s$2avu$1...@digitalmars.com...
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.
So enter the workaround code. Different compilers and different versions
will require different workaround code. Is this really reasonable for
users to put up with? And will they really want to be running the
workaround code when they upgrade the compiler and now it could have
inlined it?
I don't expect this to be a huge problem, because most functions marked with
forceinline would be trivial.
eg. setREG(ubyte val) { volatileStore(cast(ubyte*)0x1234, val); }
This function only exists to give a nicer interface to the register. If the
compiler can't inline it, I want to know about it at compilation time rather
than later.
Again, it's for those cases that would just be done with macros in C. Where
the code should always be inlined but doing it manually the source would
lead to maintenance problems.
