Doesn't GC, @nogc, safe, nothrown, * get in the way of getting things done?

[H. S. Teoh]

On Thu, Jun 11, 2020 at 11:28:07AM +0000, aberba via Digitalmars-d wrote:
> In D we have so many programming models and I'm noticing this has
> become a problem in itself.
> 
> For a example should a new HTTP library become safe, or unsafe, gc or
> no gc?  Template or no templates, reference counting?? @live??

My approach is:

1) Code minimalistically: if it's not too onerous to code without using
the GC, then code for no GC. If it's possible to get by with @safe, then
make do with @safe instead of dropping to @system. If it's possible to
be pure, strive to be pure. If it's possible to use const, do so. Etc.

To help with (1):

2) Code defensively: assume nothing other than the most essential,
indispensible assumptions to get the job done. IOW, use as few
assumptions as possible for your code to get its job done. If your
function can get the job done with 1 parameter and avoid the GC, then
don't add extra parameters just to handle some rare special case, and
don't assume the GC when it isn't absolutely necessary. Offload
complexity to the caller where it makes sense: e.g., instead of
including complex special-case handling inside your function, what about
accepting a delegate parameter that the caller can use to encode this
complexity, while your function focuses on its primary job? Coding
defensively generally also leads to more reusable code.  Which leads to:

3) Code generically: for the most part, avoid actually putting
attributes on anything. Instead, use templates -- yes, definitely use
templates, it's one of the biggest strengths of D in spite of its flaws
-- and let the compiler figure out the attributes for you.  Use
attributes on unittests that call that function to ensure that the
function body itself is pure, @nogc, etc., without putting any
attributes on the function itself.  Why? Because then your function can
be called with impure, GC, throwing, etc., arguments. Don't exclude any
users if possible.

4) Code realistically: if going @nogc, etc., will imply reinventing an
entire infrastructure from scratch and take more effort than solving the
problem domain itself, then just use the GC, use @system, ... etc., to
get the project off the ground. The GC is there for a reason; unless
you're targeting the very specific and narrow @nogc niche, there's no
need to bend over backwards to please that crowd. Use what you need to
get your job done (but no more than that -- see (1) and (2)).


> So unless its a third party library deciding to go with whatever they
> want, its going to end up in an immposible to match up to the
> technical expectations of everyone.

Of course it's impossible to please everyone.  That's why you have to
decide which audience you're targeting, and code accordingly.  Writing
*completely* generic code, in general, is quite hard. See Phobos for
example. ;-)


> Phobos is a mix of several models which sometimes fight against each
> other.  And this never gets solved cus its impossible.

Any specific examples?  In general, I find Phobos quite pleasant. (Other
than some obsolete modules that I tend to avoid anyway.) Where's this
"mix of several models which sometimes fight against each other"?


T

-- 
Without geometry, life would be pointless. -- VS