I'm going to re-iterate what deadalnix said.   I am doing this because the thread about SDC got co-opted in this forums usual fashion.

So, let me qualify:

I've been part of this community since late 2001.  We've come a long way.  However,  believe having another *good* frontend implementation is absolutely key for our success.

Let me qualify this need with some stats.  I don't mean for this list to in any way knock Walter or DMD, but rather to just stress the value of SDC to the community and also encourage people who do not want to spent the time getting over the learning curve for the DMD frontend to invest some time implementing simple things in SDC.

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!

I could go on and on about this.  But I would hope that maybe you just clone the git repo, and start fiddling around and submit some simple PRs.    We recently reorganized our git repos to make it much easier for people to get started.

Again,  I don't mean for this to come off as a knock against DMD or the work that has been done there over the last 15 years.   I also don't mean to steal any engineering resources from the DMD frontend.   Instead, I am hoping to appeal to those people, who like myself, do not have the time to understand the DMD frontend and work on it.   SDC is simple, and easy to get started on.

So again, here is our TODO list:  https://github.com/deadalnix/SDC/wiki/TODO-list

I hope you will join Amaury and myself in working on this awesome project.   We have a #slack channel set up to help us work asynchronously, and I would love it if you send me am email so I can invite you to the teamchat.   Even just having people in the channel to have discourse with would be helpful!

Cheers,
-Shammah

Please add me on #slack: marcioapm at google's email

On Saturday, 18 April 2015 at 17:21:28 UTC, Shammah Chancellor wrote:
> ...

Are there any plans for the LDC and SDC team to work together once SDC matures?

On 4/18/15 10:21 AM, Shammah Chancellor wrote:
> 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.

Agreed (as with your entire call to arms - nicely done). Where's a complete description of Go's out-of-the-box tooling? That's definitely an example we can draw inspiration from. -- Andrei

On Saturday, 18 April 2015 at 21:21:42 UTC, Andrei Alexandrescu wrote:
> On 4/18/15 10:21 AM, Shammah Chancellor wrote:
>> 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.
>
> Agreed (as with your entire call to arms - nicely done). Where's a complete description of Go's out-of-the-box tooling? That's definitely an example we can draw inspiration from. -- Andrei

here it is: https://golang.org/cmd/

many of them are also passed to go cmd as an argument. like go fmt, go vet, go test, etc.

On 4/18/15 3:08 PM, Mengu wrote:
> On Saturday, 18 April 2015 at 21:21:42 UTC, Andrei Alexandrescu wrote:
>> On 4/18/15 10:21 AM, Shammah Chancellor wrote:
>>> 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.
>>
>> Agreed (as with your entire call to arms - nicely done). Where's a
>> complete description of Go's out-of-the-box tooling? That's definitely
>> an example we can draw inspiration from. -- Andrei
>
> here it is: https://golang.org/cmd/
>
> many of them are also passed to go cmd as an argument. like go fmt, go
> vet, go test, etc.

Cool, thanks! Looking forward to tips from Go users about which tools are most appreciated and appropriate for a D incarnation. -- Andrei

On Sunday, 19 April 2015 at 05:04:56 UTC, Andrei Alexandrescu wrote:
> On 4/18/15 3:08 PM, Mengu wrote:
>> On Saturday, 18 April 2015 at 21:21:42 UTC, Andrei Alexandrescu wrote:
>>> On 4/18/15 10:21 AM, Shammah Chancellor wrote:
>>>> 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.
>>>
>>> Agreed (as with your entire call to arms - nicely done). Where's a
>>> complete description of Go's out-of-the-box tooling? That's definitely
>>> an example we can draw inspiration from. -- Andrei
>>
>> here it is: https://golang.org/cmd/
>>
>> many of them are also passed to go cmd as an argument. like go fmt, go
>> vet, go test, etc.
>
> Cool, thanks! Looking forward to tips from Go users about which tools are most appreciated and appropriate for a D incarnation. -- Andrei

gofmt, much like python's standardized formatting, made contributing to go projects much easier IMO. While the same can't be done for D, hopefully dfmt becomes a standard tool and each dub project can just include a dfmt.conf or something to make contributing easier.

I agree with the OP on the tooling point, just look at C++. C++ had historically zero(okay, some - but it sucked! ctags were awful, etc.) tooling before clang hit the scene. IMO clang/LLVM was a complete game changer for C++ tooling, and I hope D can do the same.

Clang has a static analyzer, a formatter, a modernizer...
Hell, clang(and obv. libclang) can dump the AST right from its driver, and even has autocompletion built into it(-code-completion-at)

Also, it offers many sanitizers now(undefined behavior, thread, memory, address, leak, dataflow, probably others I forgot). AFAIK a few of these are usable with LDC?

On Sunday, 19 April 2015 at 05:04:56 UTC, Andrei Alexandrescu wrote:
> Cool, thanks! Looking forward to tips from Go users about which tools are most appreciated and appropriate for a D incarnation. -- Andrei

gofmt -r 'foo -> bar' - accurate, context-sensitive renaming without need for any external tool.

On Saturday, 18 April 2015 at 20:39:56 UTC, weaselcat wrote:
> On Saturday, 18 April 2015 at 17:21:28 UTC, Shammah Chancellor wrote:
>> ...
>
> Are there any plans for the LDC and SDC team to work together once SDC matures?

I recently joined the LDC team, and I am a bit at a loss...
Should I join SDC so that I can have fun writing in D?  How big is the duplication of effort between SDC and LDC? Could LDC and SDC perhaps share druntime? (LDC has many custom changes to druntime to either use LLVM intrinsics, or rewriting of assembly routines that (I think) really only work for DMD)

-Johan

On Sunday, 19 April 2015 at 06:01:14 UTC, weaselcat wrote:
> gofmt, much like python's standardized formatting, made contributing to go projects much easier IMO. While the same can't be done for D, hopefully dfmt becomes a standard tool and each dub project can just include a dfmt.conf or something to make contributing easier.

dfmt options go in .editorconfig with the rest of your project's style decisions like tabs/spaces and line length.

> I agree with the OP on the tooling point, just look at C++. C++ had historically zero(okay, some - but it sucked! ctags were awful, etc.) tooling before clang hit the scene. IMO clang/LLVM was a complete game changer for C++ tooling, and I hope D can do the same.

For what it's worth, D-Scanner can output ctags information for D files.

> Clang has a static analyzer, a formatter, a modernizer...
> Hell, clang(and obv. libclang) can dump the AST right from its driver, and even has autocompletion built into it(-code-completion-at)

We now have a formatter. D-Scanner can perform some static analysis and dump an AST from its parser, DCD provides autocompletion. dfix can perform syntax upgrades.