[GSoC] 'Independency of D from the C Standard Library' progress and update thread

[Stefanos Baziotis]

On Monday, 3 June 2019 at 23:35:21 UTC, Mike Franklin wrote:
>
> Stefanos, everything Andrei has said here is correct, but it is 
> missing some perspective and does not consider everything we've 
> discussed.  Please STAY THE COURSE!  Do not let this post 
> discourage you.  The time for questioning the merits of this 
> proposal was 2 months ago; not now.  Now that it is a 
> full-fledged GSoC project you are tasked to do the best you can.
>
> Andrei, I agree with everything you've said, but there's more 
> to take into consideration.  I have a response to some of the 
> items you've mentioned, and maybe I'll post that later.
>
> For now allow me to express that I'm quite disappointed that 
> you are questioning the merit of this proposal when the time to 
> do so was 2 months ago when the GSoC projects were being 
> reviewed, and you were supposed to participate.  The GSoC 
> project is well underway and Stefanos now needs to see the 
> project through to completion regardless of what anyone thinks 
> about it.  Please don't undermine this project or diminish the 
> morale of our students with such posts.
>
> At the moment we need feedback on the actual memcpy 
> implementation, not whether you think this project is a good 
> idea or not.
>
> Stefanos, please don't let this post discourage you.  Please 
> STAY ON TASK.

Thank you very much Mike! Andrei, I hear you as well and thank 
you for the feedback!

I want to say this. Before about 5 days, _I_ was even unsure 
about the goals.
And in the last 5 days of writing code, I'm getting more and more 
unsure.
However, Mike is so ridiculously helpful that the last thing I 
want is to:
- Sound disheartening.
- Sound like the guy that was picked and doesn't believe in the 
project.
- Sound like the guy who writes D for 5 months and came to 
question Mike, jpf
   and any other involved in the project.

Please, for any constructive feedback, questions or anything that 
you're
unsure about, direct the message to the most relevant person. The 
facts mentioned
are not my responsibility (hopefully, for the better), so you 
probably
want to ask the mentors.

But, my opinion was asked.
First of all, for memcpy et all:
- To reach memcpy, you have to write assembly, not D. In the end 
the code
   will be bigger than memcpy because we will have the D 
improvement (what Mike
   has done), plus a memcpy-size implementation (The two 
implementations that
   you posted are not the version that gets called. You can check 
(the horror)
   if you step in a debugger. Mike had a link about what seems to 
be the
   actual implementation, but I can't find it).
- Because of the above, that code will not be D, it will be 
assembly, which
   brings one to the question "Why not use the already made asm 
versions for
   the assembly parts (like the libc version) rather than re-write 
it yourself?".
- To reach memcpy, although I'm getting good benchmarks, is next 
to impossible
   in half a summer. Yet, this is what is expected.
- Personally, I don't use dynamic arrays. My D is mostly betterC.
   For me, if people use the D features, they would probably never 
use memcpy.
   And if they don't, then they would probably use a low-level 
(unsafer?) memcpy
   with pointers. However, this is targeted to the D Runtime, with 
which I don't
   have any experience. So, I trust the mentors.

- In my opinion, the best way to go about this is to get only the
   memcpy implementation linked (so remove the dependency on 
libc), create wrappers
   around it, something like Jonathan Marler's code _and_ use D 
for the small
   sizes, where it shines (as Mike's work has already showed). 
That way you
   leverage the work that has been put on memcpy, write idiomatic 
D, remove the
   libc dependency and make a (way) faster memcpy for small sizes.

But, who am I to question things? And I don't claim in any way 
that because
my opinion is different than what we planned to do, that I 
believe that I am
correct "but hey, they decide.. right?". No. I just trust that 
they know better than me.

For malloc:
- The initial plan was that a malloc() would be written. Having 
tried to write my
   own malloc(), I say that that I was pretty naive to think I 
would do a
   replacement from scratch in half a summer. Thankfully, 
something else was
   decided. The decision to use std.experimental.allocator was not 
mine. I learned
   about it probably less than a month ago.
   I can't support if it's a bad or good decision, because I know 
very little to
   have any meaningful input. To me, it sounded good though. And 
again, I trust
   that the mentors know better (and it's not a final decision 
yet).

I don't want to sound rude. I'm grateful to the D community for 
giving me the
chance to work on something so challenging. But the project, the 
goals, the
motivation and the approach are not my responsibility.
I, of course, have opinions about those, but also my opinion is 
that: For something that I'm not in charge, better try to help 
than contradict, except if I think there's something _very_ 
wrong. And I already felt I contradicted a lot.
In the end, if the motivation is too weak, if the approach is 
wrong and
if the goals are not that desired, then why was the project 
picked?
And why are those things questioned after 2 months?

Last but not least, while this may not be the best place for 
"famous last words", I want again to thank the mentors and 
especially Mike(!). Seb as well. This project, well.. let's just 
say it didn't have exactly the warmest feedback and their
support is important.