A hypothetical question

[Ellery Newcomer]

Ary Borenszweig wrote:
> Syntax must be valid in D. I checked this in C# and it's not a
> requirement. So in this case D is better.

yeah, sort of. I had this in mind, though:

version(D1){
  int i;
}else version(D2){
  mixin("shared int i;");
}

> I think this isn't a big deal. At least in Descent full semantic
> analysis is run for the current module: the other modules are partially
> looked as needed.

Here's what I'm visualizing:

Say you have symbols A,B,C. A can be defined one of say four ways by:

version(4){
 typedef int A;
}else version(3){
 typedef real A;
}else version(2){
 typedef FoobarClass A;
}else{
 typedef FoobarUnion A;
}

or something of that nature. B and C are the same way (their respective
version conditionals are independent, though). Now say you have an
expression that contains A, B, and C and you want to deduce its type.
you have potentially 64 different types that could result from that
depending on which versions you choose.

Maybe efficiency isn't a big deal, but combinatorial growth does scare me.

> So it would be nice to check also version branches. The problem is that
> if you have a file like this:
> 
> version(Foo) {
>   // Something
> }
> 
> version(Bar) {
>   // Something else
> }
> 
> You'll have to make semantic analyis for these cases:
>  - !Foo && !Bar
>  - !Foo && Bar
>  - Foo && !Bar
>  - Foo && Bar
> 
> because each one of those combination is a valid version combination.
> Also you have to combine that with debug levels (that combination can be
> reduced by checking if there are debug versions in the affected
> modules). You might get errors with some combinations because those were
> not intended to be used together (for example Windows, Unix, etc.)
>  I think we arrived to this conclusion with Robert Fraser. :)

My current mode of thinking is that you would treat the version blocks
as if they were both there and just return multiple results when symbol
lookup could result in something in either one of them and/or in the
enclosing scope and handle analysis accordingly. But hmm, there's going
to have to be some sort of enforcement for the case when any of those
blocks get chopped.
> 
> On the other hand maybe semantic analysis can be performed with any of
> those versions. You thihk that can work? Because that'll solve a big
> problem in Descent that's: if your current version is Windows, all the
> posix/unix modules in Phobos/Tango give you an error because many things
> are not defined. The other problem is:
> 
> version(Unix) {
> } else {
>   static assert("This module should only be compiled with Unix version");
> }

Yuck. I suppose you could treat a lone static assert(false) inside a
version block as a hint... ugh more complexity..
> 
> You'll get that error in each module that looks like that if Unix
> version is not set.
> 
> So... should I try checking each version? I wouldn't know which errors
> to show (the union? that'll trigger the static assert above; the current
> version? that brings us to the beginning of this discussion).
> 

Maybe not. I don't know how descent is set up right now. Michel
suggested running separate passes for different version sets, which
would probably be easiest. Another thought I had was to group errors
hierarchically based on version and let the user control which errors
should be displayed.

> Also... Descent is still not good at showing exactly the same errors as
> DMD would give you, and probably will never be like that 

Spare me an ulcer and don't try to make it conform. In my view, unless
you have access to the guts of the compiler, your ide shouldn't try to
mimic it. It should only flag a well specified set of error conditions
and leave the rest to be flagged during the actual build. I think if you
align yourself too closely with DMD, you're setting yourself up for
trouble when other implementations of D come out, which could behave
very differently. And then there's all the incorrect and inane behavior
inside DMD, which IMO is pointless to duplicate (though maybe difficult
to identify)