utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries

[H. S. Teoh]

On Fri, May 10, 2019 at 05:16:24PM +0000, Mike Franklin via Digitalmars-d-announce wrote:
[...]
> I've studied the ARM implementation of memcpy a little, and it's quite
> hard to follow.  I'd like for the D implementations to make such code
> easier to understand and maintain.
[...]

I'm not 100% sure it's a good idea to implement memcpy in D just to
prove that it can be done / just to say that we're independent of libc.
Libc implementations of fundamental operations, esp. memcpy, are usually
optimized to next week and back for the target architecture, taking
advantage of the target arch's quirks to maximize performance. Not to
mention that advanced compiler backends recognize calls to memcpy and
can optimize it in ways they can't optimize a generic D function they
fail to recognize as being equivalent to memcpy. I highly doubt a
generic D implementation could hope to beat that, and it's a little
unrealistic, given our current manpower situation, for us to be able to
optimize it for each target arch ourselves.


> On Friday, 10 May 2019 at 05:20:59 UTC, Eugene Wissner wrote:
[...]
> > Whereby I should say that tanya‘s range definitions differ from
> > Phobos.
[..]

I'm a bit uncomfortable with having multiple, incompatible range
definitions.  While the Phobos definition can be argued whether it's the
best, shouldn't we instead be focusing on improving the *standard*
definition of ranges, rather than balkanizing the situation by
introducing multiple, incompatible definitions just because?  It's one
thing for Andrei to propose a std.v2 that, ostensibly, might have a new,
hopefully improved, range API, deprecating the current definition; it's
another thing to have multiple alternative, competing definitions in
libraries that user code can choose from.  That would be essentially
inviting the Lisp Curse.


T

-- 
Life would be easier if I had the source code. -- YHL