View mode: basic / threaded / horizontal-split · Log in · Help
February 28, 2013
Re: Are there any default dmd optimizations
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
Re: Are there any default dmd optimizations
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
Re: Are there any default dmd optimizations
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
Re: Are there any default dmd optimizations
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
Re: Are there any default dmd optimizations
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
Re: Are there any default dmd optimizations
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
Re: Are there any default dmd optimizations
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 »
3 4 5 6 7
Top | Discussion index | About this forum | D home