Multiple return values...

[Manu]

On 11 March 2012 18:45, Artur Skawina <art.08.09 at gmail.com> wrote:
>
> 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]
>

Oh don't get me started! (...oops, too late!)

This is my single greatest complaint about D, and if I were to adopt D
professionally, I would almost certainly fork the language and fix this.
virtual-by-default seems like the single biggest and most harmful
*mistake*in the whole language.
Defaulting a feature that introduces very costly damage that ONLY a WPO
pass can possibly un-do can only be described as insanity.
Choosing to do this intentionally... does DMD have a powerful WPO? >_<

I genuinely fear for this decision. Junior programmers will write really
slow code unknowingly, and it's too easy for anyone to simply forget to
declare 'final'. Seniors will spend god only knows how much time (late
nights?) trawling through the codebase verifying non-virtuals, and marking
them final, time you probably can't afford when crunching to ship a product.
Add to that the fact that *validating* a method is not overridden anywhere
is NOT a trivial task. Being able to do this with confidence will be
tedious and waste unimaginable amounts of time and frustration... and why?
What was the harm in explicit virtual? I expect explicit 'final' will
surely overwhelm virtuals in number too when considering keyword clutter
(trivial accessors, properties, etc make up the majority of methods) :/

If I were evaluating D to use commercially, this would be the biggest red
flag to consider. The time/efficiency costs could potentially be very high.

> 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).
>

So assuming that most libraries will be closed source, what's the
implication here for inlines and tempaltes long term? It sounds no
different than .h files.
Is there a plan to be able to store that metadata inside lib/object files
somehow? (I assume not, if there was, why need .di files at all)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120311/78a2fdb5/attachment-0001.html>