SDC needs you -- redux

[Martin Nowak via Digitalmars-d]

On 04/18/2015 07:21 PM, Shammah Chancellor wrote:
> 1) SDC, libd-llvm, and libd together are ~ 30KLOC of idiomatic and very
> intelligible D code.  Compare this with the 300KLOC for the DMD frontend.
>     1.1) The 30KLOC is clean and easy to get into.  It took me less than
> 3 days to get into it and start implementing language features.
>     1.2) This is enabled by the use of a scheduler to easily handle
> complex Dlang features.
>     1.3) This will enable advanced compiler normally be very difficult
> to implement
> 2) SDC supports a majority of the language at this point, the remaining
> work is mostly trivial. (When I say majority, I mean majority in terms
> of LOC needed to support, not in terms of implemented pieces of syntatic
> sugar)
>     2.1) We won't need another 250KLOC to get to 100% feature parity. 
> We're already at something like 80% feature parity by my estimation.
> 3) SDC is designed also to be a library that can used for tooling in an
> easy fashion!
>     3.1) I work with Golang on a daily basis professionally.  The
> tooling for golang is a major reason for it's adoption.  This tooling
> looks like gofix, gofmt, govet, etc.  We need this tooling to be able to
> succeed.
> 4) SDC use of fibers and a scheduler allows us to have a very robust
> error handling mechanism that DMD will never be able to implement.   We
> emit beautiful clang-style errors telling you EXACTLY what is wrong with
> your code.
> 5) SDC is fast.  It is actually faster than DMD when you move into
> template and CTFE land.
> 6) SDC leverages all the work done by the HUGE llvm group.
> 7) SDC uses the LLVM JIT for CTFE, this means no double-implementation
> of language features for CTFE, and for normal compilation.
> 8) Because SDC is written in D, is clean, and uses a JIT this opens up
> the door for actually exposing compiler AST Nodes *directly* to the code
> being compiled. (!!!!!!!!!  No more __traits horror when doing
> metaprogramming)
> 9) Because SDC is clean, easy to understand, and easy to implement
> language feature on top of, we have been able to find quite a few bugs
> in DMD.  I have been submitting bug reports back to DMD and actually
> causing the mainline D compiler to do a *better* job!

It's a really impressive list and it's very much how I'd like dmd to be
written.

I could offer to work on dub and travis-ci integration, but there
doesn't even seem to exists a cmdline interface?

bin/sdc --help
HELP !
core.exception.RangeError at sdc/src/sdc/main.d(51): Range violation

Also some of the TODO items really look very feasible.
https://github.com/deadalnix/SDC/issues/125

What I'd like to see though, is a prioritized list of stuff that needs
to be done to reach a working D style hello world.

And at some point you need to get rid of stack traces of the compiler on
compile errors.