Sorry, did not mean this to be private...
----- Forwarded Message -----
>From: Steve Schveighoffer <[email protected]>
>To: Don Clugston <[email protected]>
>Sent: Friday, September 16, 2011 8:57 AM
>Subject: Re: [dmd-internals] Fixing forward ref bugs for good
>
>
>What I mean is, it feels like the wrong approach to ordering. I'd rather
>ordering be dependent on ordering, not nesting. It seems like a
>counter-intuitive way to do ordering that has the same issues using the order
>of declaration.
>
>
>
>People are going to look at some file that has static if(true) (or several
>levels of them!) and scratch their heads, potentially removing it.
>
>
>Are we trying to say here, ordering matters only for static ifs? Then why
>can't the ordering just be the order they appear? Is there any advantage to
>use nesting? What about some sort of pragma or @annotation to define ordering?
>
>
>And what about repeatedly trying evaluating a static if until it can be
>evaluated, or you are stuck? Has that been considered and rejected for some
>reason?
>
>
>Again, not understanding all the issues, so maybe it's just the only way
>possible. But it sure looks bad.
>
>
>
>-Steve
>
>
>
>
>>________________________________
>>From: Don Clugston <[email protected]>
>>To: Steve Schveighoffer <[email protected]>; Discuss the internals of DMD
>><[email protected]>
>>Sent: Friday, September 16, 2011 8:37 AM
>>Subject: Re: [dmd-internals] Fixing forward ref bugs for good
>>
>>On 16 September 2011 13:25, Steve Schveighoffer <[email protected]> wrote:
>>> Not really understanding all the issues here, but this looks horrible :(
>>> I hope this isn't the solution.
>>> -Steve
>>
>>Are you reacting to the concept, or only to the syntax?
>>Bear in mind that it occurs ONLY when you have dependent static ifs
>>within a single scope.
>>For example, if you have a 'static if' inside a template, struct, or
>>function, it has access to ALL symbols in that module.
>>In my opinion, this normally (not always, but normally) indicates a
>>poor design. It can almost always be factored out (eg, by creating a
>>bool enum). Worst case, we could add some syntax sugar.
>>I think that if
you really want to have semantics which are
>>independent of the ordering of declarations, then by definition you
>>can't have dependent static ifs in the same scope.
>>The second option is to allow ordering to be significant only for
>>mixins and static if. And in that case, the ordering has to be strict:
>>even if something near the end of the file is 'static if(1)', the
>>declarations in it are not available anywhere else in the scope.
>>I think any other option (like evaluating every static if that doesn't
>>use is(typeof()) or other forms of reflection, before those that do)
>>leads to madness.
>>
>>
>>> From: Don Clugston <[email protected]>
>>> On 15 September 2011 17:56, Andrei Alexandrescu <[email protected]> wrote:
>>>> On 9/15/11 6:53 AM,
Don Clugston wrote:
>>>>>
>>>>> On 15 September 2011 13:14,<[email protected]> wrote:
>>>>>>
>>>>>> Am 15.09.2011, 11:44 Uhr, schrieb Don
>>>>>> Clugston<[email protected]>:
>>>>>>>
>>>>>>> I think there is a simple solution to 'static if'.
>>>>>>> Do const folding on every static if condition, giving a boolean result.
>>>>>>> Do NOT evaluate any static if bodies yet.
>>>>>>> This would have the same effect as if every 'static if' were evaluated
>>>>>>> simultaneously.
>>>>>>
>>>>>> What if the condition includes symbols from another static if's body or
>>>>>> mixin or
whatever?
>>>>>
>>>>> I think that should be disallowed.
>>>>
>>>> I see an issue here with cross-module use. For example, it's nice to have:
>>>>
>>>> import some.module;
>>>>
>>>> static if (is(typeof(some.module.foobar) == int)) {
>>>> alias some.module.foobar baz;
>>>> } else {
>>>> enum baz = 42; // or whatever
>>>> }
>>>>
>>>> So far so good. The problem now is that some.module uses a similar
>>>> technique
>>>> to introduce that symbol foobar, the code won't work anymore.
>>>>
>>>> I also realized that code relying on enumerating symbols in a module (like
>>>> benchmark does) or a class (like an introspection library does) will miss
>>>> all symbols guarded by static if. And, for example, ranges define plenty
>>>> of
>>>> those. This erodes the power of static if
substantially.
>>>
>>> Not so. The thing is, static ifs can be nested. Only one level of
>>> static if is removed at a time.
>>> If you simply wrap the static if inside static if(true) {...}
>>> it won't be evaluated until all the first-level static ifs have added
>>> their symbols to the scope.
>>>
>>> So the current:
>>> static if (cond1)
>>> {
>>> A;
>>> }
>>> static if (cond2)
>>> {
>>> B;
>>> }
>>> where cond2 depends on A, can be rewritten in the 'parallel execution'
>>> paradigm as:
>>> static if (cond1)
>>> {
>>> A;
>>> }
>>> static if (true)
>>> {
>>> static if (cond2)
>>> {
>>> B;
>>> }
>>> }
>>> Order of execution is controlled by depth of nesting, instead of by
>>> order in the file.
>>> Note that in your first example, the question of which
module
>>> instantiates the symbol is determined not even by order within the
>>> file, but by which module is first on the command line -- ie, it's
>>> determined by the makefile!
>>> _______________________________________________
>>> dmd-internals mailing list
>>> [email protected]
>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>>
>>>
>>>
>>> _______________________________________________
>>> dmd-internals mailing list
>>> [email protected]
>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>>
>>
>>
>>
>
>_______________________________________________
dmd-internals mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals
