Creeping Bloat in Phobos

[via Digitalmars-d]

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.