Multiple return values...

[Artur Skawina]

On 03/11/12 15:59, Manu wrote:
> On 11 March 2012 16:01, Artur Skawina <art.08.09 at gmail.com <mailto:art.08.09 at gmail.com>> wrote:
> 
>     > which I don't imagine D will be able to support any time real soon?
> 
>     In fact, until GDC learns cross-module inlining, using these modes is the only
>     way to make the compiler generate sane code
> 
> 
> Yeah I'm very concerned by this currently. But it seems to we a well known issue with a plan/intent to fix it right?
> (Side note: I'd still really like an explicit @forceinline attribute)

Just '@forceinline' is IMHO too specific and not enough  -- because you also want
@noinline, @noclone, @flatten, @cold and more of theses kind of /generic/ attributes,
not to mention the target-specific ones. So a way to specify function (and data)
attributes is needed, together with a way to bundle them. Maybe something like
"alias @attr(noinline, noclone, cold, nothrow) @errorpath;".


>     > ...and even then, relying on WPO for the language to generate good code in certain circumstances is a really really bad idea. This makes the task of implementing an efficient compiler for the language extremely difficult.
> 
>     There is a reason why i never even considered trying out a non-gcc-based D compiler... [1]
> 
>     For a language like D, WPO in some form is almost required; w/o it you'd need to
>     always think about how the compiler will treat your code; which, while possible,
>     would often result in more "unnatural" and tricky solutions. (In C/C++ there's
>     a *.h/*.c split, which helps mitigate the problem)
> 
> 
> "think about how the compiler will treat your code" ... "'unnatural' and tricky solutions" ... Outside of cross module inlining, what are some other common problem cases?
> 
> C/C++ .h files only really simplify 2 things, inlining, and templates, but I can't see how the situation is any different in D?

Traditionally, the pre-WPO way, the coder would put the things expected to become
part of the caller in header files. In D, header files are unnecessary, other than
for the binary-lib-interface case. And currently even if you duplicate part of the
code in a *.di file, it doesn't really change anything, other than preventing some
optimizations like inlining or cloning (for the omitted parts).

If you have a complex data type which exports eg a range, you may want just '.front'
etc to be inlined, and creating a *.di file just for this purpose shouldn't be 
required. Template definitions need to be visible to the caller/user too - having
to place them all in a *.di file would not be a good solution - in many cases
most of the code would move there...

Other than that, there is devirtualization - D does not have 'virtual'; the compiler
can still do it and even inline the virtual methods, but it needs to know that
nothing overrides the functions - impossible w/o WPO for public non-final classes. [1]

> My understanding is that templates depends on .d/.di files being present during compilation? So why doesn't D do inlining the same way? If I declare some inline function in a .d/.di file, surely it should be capable of inlining?
> C/C++ can't inline something from a foreign object either without a definition in a header...

It's the same for D, I just don't think *.di files should be necessary for _internal_
cross-module interfaces, or when the full source is available anyway.
Currently, cross-module inlining is a problem for GDC, but even when that's fixed,
WPO will help things like devirtualization or changing calling conventions (gcc does
it already, but i don't know if it clones non-local functions just for this, when not
in WPO mode).

artur

[1] BTW, this means that a "@virtual" attribute might be needed - to prevent
    devirtualizing methods for classes used by plugins or other dynamically loaded code.