February 28, 2013
On Wednesday, 27 February 2013 at 21:57:06 UTC, Andrei Alexandrescu wrote:
> On 2/27/13 3:16 PM, Jacob Carlborg wrote:
>> On 2013-02-27 14:29, Andrei Alexandrescu wrote:
>>
>>> Four years ago I would've entirely agreed. But right now it's an odd
>>> comment to make seeing as we're discussing all major decisions in this
>>> group and we're switching full-bore to DIPs.
>>
>> The "alias this" syntax the foobar mentioned was removed under the radar
>> and only discussed in a pull request.
>
> I agree we were sloppy on that. Kenji was feeling strong about and Walter and I didn't have particular objections, so we gave him green light. In the process we neglected backward compatibility.
>
> Andrei

At a bare minimum, there should be a well defined place to notify *users* (NOT DMD contributers) about language changes *ahead of time*. If such place is not defined, than people do not know where to look for that info if that is even available at all. This at least will remove the element of surprise.

For D to be really open as it claims to be, there should be additional guidelines about the decision making process itself. This should be made accessible for *users* (D programmers). I need not be a core DMD contributer, nor should I need to know C++ or DMD's internals, Nor should I need to browse among hundreds of bugs on bugzilla or pull requests on github (both can be labeled very poorly) to discern out of that sea of information what are the *few* visible changes to the language and core library APIs.
February 28, 2013
On 02/28/2013 05:55 AM, Walter Bright wrote:
> On 2/27/2013 8:01 PM, deadalnix wrote:
>> Plus, this is really hard to ensure that everything is initialized
>> properly
>> without going eager with setting to init.
>
> Yeah, the forward reference order of evaluation thingie.

It's really easy. DMD can be convinced to do a sufficient conservative analysis even now, but the behaviour is undocumented and seems unintentional.


    void main() {
        void foo()() { bar(); }
        void bar()() { i = 3; }
        int i;
        foo();
    }

It's a fine idea to disallow the use of both a shadowed and the shadowing symbol in the same function anyway, so we wouldn't lose a lot by allowing forward references from local functions.

Then the template behaviour could be fixed:

int i = 0;

void main(){
    void foo(int x){ i = x; }
    foo(1);
    int i = 0;
    foo(2);
    assert(.i==2&&i==0);
}

int i = 0;

void main(){
    void foo(int x){ i = x; }
    // foo(1);
    int i = 0;
    foo(2);
    assert(.i==0&&.i==2);
}

(Currently, presence of one call can magically influence the behaviour of other calls.)
February 28, 2013
On 2/28/13, Timon Gehr <timon.gehr@gmx.ch> wrote:
> It's really easy. DMD can be convinced to do a sufficient conservative analysis even now, but the behaviour is undocumented and seems unintentional.
>
>
>      void main() {
>          void foo()() { bar(); }
>          void bar()() { i = 3; }
>          int i;
>          foo();
>      }

You can even make them non-templates if they're part of a mixin template.

mixin template T()
{
    void foo() { bar(); }
    void bar() { i = 3; }
    int i;
}

void main()
{
    mixin T!();
    foo();
}
February 28, 2013
On 2/28/2013 11:03 AM, Timon Gehr wrote:
> It's really easy. DMD can be convinced to do a sufficient conservative analysis
> even now, but the behaviour is undocumented and seems unintentional.
>
>
>      void main() {
>          void foo()() { bar(); }
>          void bar()() { i = 3; }
>          int i;
>          foo();
>      }

No, the compiler is not being clever here, nor is this undocumented. Templates are not semantically analyzed until they are instantiated. In fact, they can't be semantically analyzed until they are instantiated.

February 28, 2013
On 03/01/2013 12:01 AM, Walter Bright wrote:
> On 2/28/2013 11:03 AM, Timon Gehr wrote:
>> It's really easy. DMD can be convinced to do a sufficient[ly] conservative
>> analysis
>> even now, but the behaviour is undocumented and seems unintentional.
>>
>>
>>      void main() {
>>          void foo()() { bar(); }
>>          void bar()() { i = 3; }
>>          int i;
>>          foo();
>>      }
>
> No, the compiler is not being clever here,

I wasn't stating that.

> nor is this undocumented.

Where is it documented?

> Templates are not semantically analyzed until they are instantiated.  In
> fact, they can't be semantically analyzed until they are instantiated.
>

Obviously. In the above code all templates are instantiated. This is about which state of the function local symbol table is used.
March 01, 2013
On 2/28/2013 3:07 PM, Timon Gehr wrote:
> On 03/01/2013 12:01 AM, Walter Bright wrote:
>> On 2/28/2013 11:03 AM, Timon Gehr wrote:
>>> It's really easy. DMD can be convinced to do a sufficient[ly] conservative
>>> analysis
>>> even now, but the behaviour is undocumented and seems unintentional.
>>>
>>>
>>>      void main() {
>>>          void foo()() { bar(); }
>>>          void bar()() { i = 3; }
>>>          int i;
>>>          foo();
>>>      }
>>
>> No, the compiler is not being clever here,
>
> I wasn't stating that.
>
>> nor is this undocumented.
>
> Where is it documented?

Under templates, it says that templates are instantiated in the scope of the corresponding template declaration.

At the time of foo(); bar has been added to the scope.


> Obviously. In the above code all templates are instantiated. This is about which
> state of the function local symbol table is used.

C++ has the notion of point of instantiation and point of definition, with D, it's about scope of instantiation and scope of definition instead.
March 01, 2013
On 2/28/2013 10:32 AM, foobar wrote:
> At a bare minimum, there should be a well defined place to notify *users* (NOT
> DMD contributers) about language changes *ahead of time*. If such place is not
> defined, than people do not know where to look for that info if that is even
> available at all. This at least will remove the element of surprise.

The mailing lists serve that purpose, and the discussion was on the mailing list (which is an echo of what happens on github). It also showed up in the bugzilla n.g., as do all things posted on bugzilla.

You could argue that there's too much other 'noise' on those things. But at what point can one decide what is 'noise' and what isn't? Everybody has a different set of things they want to watch.

> For D to be really open as it claims to be, there should be additional
> guidelines about the decision making process itself. This should be made
> accessible for *users* (D programmers). I need not be a core DMD contributer,
> nor should I need to know C++ or DMD's internals, Nor should I need to browse
> among hundreds of bugs on bugzilla or pull requests on github (both can be
> labeled very poorly) to discern out of that sea of information what are the
> *few* visible changes to the language and core library APIs.

All of the changes affects somebody, otherwise they would never have gotten onto bugzilla in the first place.

There are searches you can make on bugzilla for fulfilled enhancements only, such as:

http://d.puremagic.com/issues/buglist.cgi?chfieldto=Now&query_format=advanced&chfield=resolution&chfieldfrom=2013-02-18&chfieldvalue=FIXED&bug_severity=enhancement&bug_status=RESOLVED&version=D2&version=D1%20%26%20D2&resolution=FIXED&product=D


Next ›   Last »
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home