Peter Alexander wrote:
> I don't mean to be negative, but it would really help the language if there was a complete spec. Until there is, people will be reluctant to fix bugs, nobody is going to attempt to write another compiler, and certainly no one can write better documentation if they don't know how things work.


I think you've identified an area where you can contribute to D! Identify where the problems are in the spec, and propose patches. Stewart has done a lot of that, but more needs to be done.

On Sun, 24 Oct 2010 01:33:33 +0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Denis Koroskin:
>
>> FWIW, similar problem exists:
>>
>> class Foo
>> {
>>      void foo1()
>>      {
>>          struct Bar {}
>>      }
>>
>>      void foo2()
>>      {
>>          struct Bar { /* different set of fields and methods */ }
>>          // using Foo.foo2.Bar here
>>          // bang! linker errors
>>      }
>> }
>
> I have tried this, with no errors:
>
>
> class Foo {
>     void foo1() {
>         struct Bar { string s; }
>     }
>
>     void foo2() {
>         struct Bar { int x;
>             int spam() { return 1; }
>         }
>         Bar b = Bar(10);
>         int y = b.spam();
>     }
> }
>
> void main() {
>     auto f = new Foo;
>     f.foo2();
> }
>
>
> Are you able to show me code (or a bug report) that doesn't work?
>
> Bye,
> bearophile

Slightly modified yours and here we go:

class Foo {
    void foo1() {
        struct Bar {
            string s;
            void spam() {
            }
        }

        Bar b = Bar("hello");
        b.spam();
    }

    void foo2() {
        struct Bar {
            int x;
            int spam() { return 1; }
        }
        Bar b = Bar(10);
        int y = b.spam();
    }
}

void main() {
    auto f = new Foo;
    f.foo1();
//    f.foo2();	// uncommenting produces different crash
}

Peter Alexander Wrote:

> For example, a recent bug regards the validity of:
> 
> void main()
> {
>    { static int x; }
>    { static int x; }
> }

Code is obviously valid. Storage has nothing to do with visibility. In fact, local static variables were introduced in order to shrink scope of global variables.

Kagamin wrote:
> Peter Alexander Wrote:
> 
>> For example, a recent bug regards the validity of:
>> 
>> void main() { { static int x; } { static int x; } }
> 
> Code is obviously valid. Storage has nothing to do with visibility. In fact,
> local static variables were introduced in order to shrink scope of global
> variables.

Yes, I agree that should be valid.

On Sat, 23 Oct 2010 16:09:37 +0100, Peter Alexander wrote:

> Should people work on other D compilers (gdc and ldc in particular)? Is this even possible without a formal language specification?

God, I hope so, because I've already sunk enough time into SDC. I'd like to have a usable compiler at the end! xD

== Quote from Bernard Helyer (b.helyer@gmail.com)'s article
> On Sat, 23 Oct 2010 16:09:37 +0100, Peter Alexander wrote:
> > Should people work on other D compilers (gdc and ldc in particular)? Is this even possible without a formal language specification?
> God, I hope so, because I've already sunk enough time into SDC. I'd like to have a usable compiler at the end! xD

I hope so too!

On 23/10/2010 16:09, Peter Alexander wrote:
> There have been threads about what the biggest issues with D are, and
> about the top priorities for D are, but I don't think there has been a
> thread about what the best things are that the community can do to help D.
>
> Should people try to spread the word about D? I'm not even sure this is
> a good idea. We all know that D2 is far from stable at the moment, and
> getting people to try D in its current state might actually put them off
> (first impressions are very important).
>
> Should people try to help with dmd and Phobos? If so, what are the best
> ways to do that?
>
> Should people work on other D compilers (gdc and ldc in particular)? Is
> this even possible without a formal language specification?
>
> What else can we do to help? And what would we consider to be the *best*
> ways to help?

If you have good /Java skills/, the DDT project welcomes contributions (http://code.google.com/a/eclipselabs.org/p/ddt/).

The *best* ways to help, it depends on your skills and area of experience. One person may be much more useful and/or productive for the D community doing one thing versus another.

But if you want to know which areas are better to have contributions made, in my opinion it's the compilers, especially DMD. Second to that I would say the rest of the toolchain (IDEs, build tools, debuggers).

-- 
Bruno Medeiros - Software Engineer