On Sunday, 28 September 2014 at 21:00:46 UTC, Dmitry Olshansky
wrote:
29-Sep-2014 00:33, Andrei Alexandrescu пишет:
The right solution here is refcounted exception plus
policy-based
functions in conjunction with RCString. I can't believe this
focus has
already been lost and we're back to let's remove autodecoding
and ban
exceptions. -- Andrei
Consider what end users are going to use first, then design the
library to fit the use cases while retaining general usefulness.
If UTF-8 decoding cannot be efficiently done as a generic adapter
then D's approach to generic programming is a failure: dead on
arrival.
Generic programming is not supposed to be
special-case-everything-programming. If you cannot do generic
programming well on strings, then don't. Provide a concrete
single dedicated utf-8 string type instead.
I've already stated my perception of the "no stinking
exceptions", and "no destructors 'cause i want it fast"
elsewhere.
Code must be correct and fast, with correct being a
precondition for any performance tuning and speed hacks.
Correct usually entails exceptions and automatic cleanup. I
also do not believe the "exceptions have to be slow" motto,
they are costly but proportion of such costs was largely
exaggerated.
Correctness has nothing to do with exceptions and an
exception-specific cleanup model. It has to with having a well
specified model of memory management, understanding the model and
implementing code to the model with rigour.
The alternative is to have isolates only, higher level constructs
only, GC everywhere and uniform activision-records for everything
(no conceptual stack). Many high level languages work this way,
even in the 60s.
When it comes to exception efficiency you have many choices:
1. no exceptions, omit frame pointer
2. no extra overhead when not throwing, standard codegen and
linking, slow unwind
3. no extra overhead when not throwing, nonstandard codegen,
faster unwind
4. extra overhead when not throwing, nonstandard codegen, fast
unwind
5. small extra overhead when not throwing, no RAII/single
landingpad, omit frame pointer possible, very fast unwind
(C-style longjmp)
6. hidden return error value , fixed medium overhead
D has selected standard C++ (2), which means low overhead when
not throwing and that you can use regular C backend/linker. In a
fully GC language I think that (5) is quite acceptable and what
you usually want when doing a web service. You just bail out to
the root and you never really acquire resources except for
transactions that should be terminated in the handler before
exiting (and they will time out anyway).
But there is no best model. There are trade offs based on what
kind application you write.
So as usual it comes back to this: what kind of applications are
D actually targeting?
D is becoming less and less a system level language, and more a
more a compiled scripting framework.
The more special casing, the less transparent D becomes, and the
more of a scripting framework it becomes.
A good system level language requires transparency:
- easy to visualize memory layout
- predictable compilation of code to machine language
- no fixed memory model
- no arbitrary limits and presumptions about execution model
- allows you to get close to the max hardware performance
potential
I have a hard time picturing D as a system level language these
days. And the "hacks" that try to make it GC free are not making
it a better system level language (I don't consider @nogc to be a
hack). It makes D even less transparent.
Despite all the flaws of the D1 compiler, D1 was fairly
transparent.
You really need to decide if D is supposed to be primarily a
system level programming or if it is supposed to provide system
level programming as an after thought on top of an application
level programming language.
Currently it is the latter and more so for every iteration.
