On Sat, Jan 17, 2009 at 6:26 AM, Yigal Chripun <yigal100@gmail.com> wrote:
> bearophile wrote:
>>
>> Bill Baxter:
>>>
>>> To me it's hard to see those variable declarations as being anything
>>> other than scoped to the blocks they're in.
>>> So all I'm saying is if we could have some different delimiters for
>>> non-scope blocks then it might be nice, and make it easier to see when
>>> scopes are ending and when they are not.
>>
>> *Now* I understand, and I see your point.
>> It's the usual problem: ASCII doesn't have enough ways to represent
>> containers and delimiters :-)
>>
>> So if this is your original code (I have improved your indentations and improved readability a little):
>>
>> [...]
>>
>> I don't think lot of people will appreciate those.
>> So the lack of different block delimiters may make this problem have no
>> better solution.
>>
>> Bye,
>> bearophile
>
> in C# they use the same syntax as the c pre-processor for conditional compilation and such even though C# doesn't have a pre-processor and the syntax is interpreted by the compiler. the above would be something like:
>
>  void doSomething(T)(int i) {
>      if (i == 0) {
>          #if (is(T == A))
>              A.SomeAlias x;
>          #elif (is(T == B))
>              B.SubType x;
>          #else
>              T x;
>          #endif
>
>          x = ... whatever
>     }
>     else
>          int y = x;
>  }
>
> D can always revert to this kind of syntax for compile time code.


I kinda like that, actually, but I doubt it'll be very popular around here.

--bb

Bill Baxter wrote:
> [snip]
>> in C# they use the same syntax as the c pre-processor for conditional compilation and such even though C# doesn't have a pre-processor and the syntax is interpreted by the compiler. the above would be something like:
>>
>>  void doSomething(T)(int i) {
>>      if (i == 0) {
>>          #if (is(T == A))
>>              A.SomeAlias x;
>>          #elif (is(T == B))
>>              B.SubType x;
>>          #else
>>              T x;
>>          #endif
>>
>>          x = ... whatever
>>     }
>>     else
>>          int y = x;
>>  }
>>
>> D can always revert to this kind of syntax for compile time code.
> 
> 
> I kinda like that, actually, but I doubt it'll be very popular around here.
> 
> --bb

The '#' has a nice connotation for anyone who's used to C/C++, given that those statements are handled at "compile time."  The problem, of course, is that they're really nothing like C preprocessor statements. They have a different syntax, and completely different capabilities. What's more, you can't mix them across statements/expressions, so I suspect it would just cause more confusion.

Additionally, there's this:

   #endif

Unless you plan on moving all control structures to BASIC/pascal style, I don't think it's wise to start mixing them all over the place.

I do like the idea of a "scopeless block" syntax in theory, though it's not something that's really been an issue for me.

  -- Daniel

On Sat, 17 Jan 2009 06:17:57 +0300, Daniel Keep <daniel.keep.lists@gmail.com> wrote:

>
>
> Bill Baxter wrote:
>> [snip]
>>> in C# they use the same syntax as the c pre-processor for conditional
>>> compilation and such even though C# doesn't have a pre-processor and the
>>> syntax is interpreted by the compiler. the above would be something like:
>>>
>>>  void doSomething(T)(int i) {
>>>      if (i == 0) {
>>>          #if (is(T == A))
>>>              A.SomeAlias x;
>>>          #elif (is(T == B))
>>>              B.SubType x;
>>>          #else
>>>              T x;
>>>          #endif
>>>
>>>          x = ... whatever
>>>     }
>>>     else
>>>          int y = x;
>>>  }
>>>
>>> D can always revert to this kind of syntax for compile time code.
>>
>>
>> I kinda like that, actually, but I doubt it'll be very popular around here.
>>
>> --bb
>
> The '#' has a nice connotation for anyone who's used to C/C++, given
> that those statements are handled at "compile time."  The problem, of
> course, is that they're really nothing like C preprocessor statements.
> They have a different syntax, and completely different capabilities.
> What's more, you can't mix them across statements/expressions, so I
> suspect it would just cause more confusion.
>
> Additionally, there's this:
>
>    #endif
>
> Unless you plan on moving all control structures to BASIC/pascal style,
> I don't think it's wise to start mixing them all over the place.
>
> I do like the idea of a "scopeless block" syntax in theory, though it's
> not something that's really been an issue for me.
>
>   -- Daniel

Well, syntax could be different:

void doSomething(T)(int i) {
   if (i == 0) {
       #if (is(T == A)) {
           A.SomeAlias x;
       #} else if (is(T == B)) {
           B.SubType x;
       #} else {
           T x;
       #}

       x = ... whatever
   }
   else
       int y = x;
}

But I don't see how '#' at the beginning is useful.

Denis Koroskin:
> void doSomething(T)(int i) {
>     if (i == 0) {
>         #if (is(T == A)) {
>             A.SomeAlias x;
>         #} else if (is(T == B)) {
>             B.SubType x;
>         #} else {
>             T x;
>         #}
> 
>         x = ... whatever
>     }
>     else
>         int y = x;
> }

A different possibility is to use {# ...  #}

        static if (is(T == A)) {#
            A.SomeAlias x;
        #} else if (is(T == B)) {#

Bye,
bearophile

On 2009-01-16 22:17:57 -0500, Daniel Keep <daniel.keep.lists@gmail.com> said:

> The '#' has a nice connotation for anyone who's used to C/C++, given
> that those statements are handled at "compile time."  The problem, of
> course, is that they're really nothing like C preprocessor statements.
> They have a different syntax, and completely different capabilities.
> What's more, you can't mix them across statements/expressions, so I
> suspect it would just cause more confusion.
> 
> Additionally, there's this:
> 
>    #endif
> 
> Unless you plan on moving all control structures to BASIC/pascal style,
> I don't think it's wise to start mixing them all over the place.

All good reasons, but there is one more:

If you use #if in the standard D language, then it'll make it harder to use a real C preprocessor when you need it. D has support for #line in the language so that the compiler gives you error messages relative to the right included file and line in a preprocessor output. D doesn't have a preprocessor built-in, and doesn't recommand using one either, but it has support for it. Introducing #if in the D language would break that support.


> I do like the idea of a "scopeless block" syntax in theory, though it's
> not something that's really been an issue for me.

Me neither.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

"Michel Fortin" <michel.fortin@michelf.com> wrote in message news:gksbop$2ttr$1@digitalmars.com...
> On 2009-01-16 22:17:57 -0500, Daniel Keep <daniel.keep.lists@gmail.com> said:
>
>> The '#' has a nice connotation for anyone who's used to C/C++, given that those statements are handled at "compile time."  The problem, of course, is that they're really nothing like C preprocessor statements. They have a different syntax, and completely different capabilities. What's more, you can't mix them across statements/expressions, so I suspect it would just cause more confusion.
>>
>> Additionally, there's this:
>>
>>    #endif
>>
>> Unless you plan on moving all control structures to BASIC/pascal style, I don't think it's wise to start mixing them all over the place.
>
> All good reasons, but there is one more:
>
> If you use #if in the standard D language, then it'll make it harder to use a real C preprocessor when you need it. D has support for #line in the language so that the compiler gives you error messages relative to the right included file and line in a preprocessor output. D doesn't have a preprocessor built-in, and doesn't recommand using one either, but it has support for it. Introducing #if in the D language would break that support.
>
>
>> I do like the idea of a "scopeless block" syntax in theory, though it's not something that's really been an issue for me.
>
> Me neither.
>

The only time I've had a problem with any scope/scopeless block issue is having gotten bitten once by the inability to use a mixin to declare a scope object (since it only lives within the mixin's own implicit scope and not the scope where the mixin is instantiated (as I would have expected)...which does seem odd now that I think about it, because an "int a", for instance, declared inside a mixin still outlives the mixin, even though I don't think that happens with an explicit block). But that doesn't really need a special "scopeless block" syntax to be fixed.