On Thursday, 29 May 2014 at 18:12:10 UTC, Dmitry Olshansky wrote:
> And no, it doesn't matter how the current frontend implements it, because you can argue next to any decisions this way.

When issues like this come up the spec is almost always changed to match the DMD front end instead of the other way around.

Why are we afraid of breaking code that relied on behavior that was not in the language specification? That makes it almost impossible to fix accepts-invalid bugs.

On Thu, 29 May 2014 14:11:27 -0400, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

> 29-May-2014 04:58, Walter Bright пишет:
>> On 5/28/2014 5:35 PM, Brian Rogoff wrote:
>>> Could you elaborate? Using some of the examples Brian gave, which ones
>>> do you
>>> think are are mathematically consistent/human inconsistent and which
>>> the inverse?
>>
>> Off the top of my head:
>>
>>      static if (condition)
>>      else :
>>
>>      ... declarations ...
>>
>> All attributes apply to either:
>>
>> 1. the next statement or declaration
>> 2. { ... }
>> 3. : ...
>>
>> That case is (3), as static if is set up as an attribute.
>>
>
> Static if is certainly NOT an attribute, it doesn't make any sense.

Well... it sorta does. static if does not introduce a new scope, even with {}, and this only happens with attributes.

-Steve

On Thursday, 29 May 2014 at 18:52:53 UTC, Brian Schott wrote:
> On Thursday, 29 May 2014 at 18:12:10 UTC, Dmitry Olshansky wrote:
>> And no, it doesn't matter how the current frontend implements it, because you can argue next to any decisions this way.
>
> When issues like this come up the spec is almost always changed to match the DMD front end instead of the other way around.

I believe that the result of this policy will be that the D community will need to have Scott Meyers or someone like him to explain some of these issues. :-)

It may not be as bad as C++, but is that how we want to measure a language design? "Sure, it looks bad, but it could have been so much worse!"

> Why are we afraid of breaking code that relied on behavior that was not in the language specification?

My guess is that the fear of 'breaking' some users' code is too great right now. That was one of the things I took from Meyers' talk; the D designers still have an opportunity to be bold in introducing changes that make the entire design better (more easily explainable) while in C++ that opportunity has probably passed.

> That makes it almost impossible to fix accepts-invalid bugs.

It's a problem that needs to be addressed. Thanks for your efforts and for continually reminding people. I really liked your lightning talk; it could have followed Meyers' and maybe the right people would have been shamed into action.

29-May-2014 23:06, Steven Schveighoffer пишет:
> On Thu, 29 May 2014 14:11:27 -0400, Dmitry Olshansky
> <dmitry.olsh@gmail.com> wrote:
>
>> 29-May-2014 04:58, Walter Bright пишет:
>>> On 5/28/2014 5:35 PM, Brian Rogoff wrote:
>>>> Could you elaborate? Using some of the examples Brian gave, which ones
>>>> do you
>>>> think are are mathematically consistent/human inconsistent and which
>>>> the inverse?
>>>
>>> Off the top of my head:
>>>
>>>      static if (condition)
>>>      else :
>>>
>>>      ... declarations ...
>>>
>>> All attributes apply to either:
>>>
>>> 1. the next statement or declaration
>>> 2. { ... }
>>> 3. : ...
>>>
>>> That case is (3), as static if is set up as an attribute.
>>>
>>
>> Static if is certainly NOT an attribute, it doesn't make any sense.
>
> Well... it sorta does. static if does not introduce a new scope, even
> with {}, and this only happens with attributes.

Let it be just a declaration, as simple as that. Attributes affect other declarations in the scope, static if doesn't.

>
> -Steve


-- 
Dmitry Olshansky

On 5/29/2014 11:11 AM, Dmitry Olshansky wrote:
> Static if is certainly NOT an attribute, it doesn't make any sense.

Yes, it does make sense. It was not an accident that the frontend treats it as it does, the code to do it was deliberately put there.

The attributes are all designed to affect a block of code - so are version/debug/staticif - why should they be different?

On Thu, 29 May 2014 15:24:06 -0400, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

> Let it be just a declaration, as simple as that. Attributes affect other declarations in the scope, static if doesn't.

Sure it does:

private:
   int a;
   int b;

equivalent to

private int a;
private int b;

static if(x):
   int a;
   int b;

equivalent to

static if(x) int a;
static if(x) int b;

;)

Yes, I agree static if does not fit the understood meaning of an attribute. And it can apply to statements too, whereas attributes can only apply to declarations (right?).

In reality, static if is in a league with version and debug, and they share similarities to both statements and attributes.

-Steve

On 5/29/2014 11:25 AM, Dmitry Olshansky wrote:
> Agreed. The simple dream of automatically decoding UTF and staying "Unicode
> correct" is a failure.

Yes. Attempting to hide the fact that strings are UTF-8 is just doomed. It's like trying to pretend that floating point does not do rounding.

It's far more practical to embrace what it is and deal with it. Yes, D programmers will need to understand what UTF-8 is. I don't see any way around that.

My proposal for dealing with this, while retaining backwards compatibility, is adding the ranges byCodeunit, byChar, byWchar and byDchar which can be applied to any string arrays or string ranges.

On Thu, 29 May 2014 15:29:31 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 5/29/2014 11:11 AM, Dmitry Olshansky wrote:
>> Static if is certainly NOT an attribute, it doesn't make any sense.
>
> Yes, it does make sense. It was not an accident that the frontend treats it as it does, the code to do it was deliberately put there.
>
> The attributes are all designed to affect a block of code - so are version/debug/staticif - why should they be different?

private int x; // ok
static if(1) int x; // ok

private x = 5; // error
static if(1) x = 5; // ok

Static if/version/debug can affect both statements and declarations. attributes only apply to declarations. That is the major difference I see between them.

Not arguing that it's bad for the syntax to exist, I think it kind of makes sense given that static if does not create a new scope. But they don't behave like normal attributes.

-Steve

29-May-2014 23:29, Walter Bright пишет:
> On 5/29/2014 11:11 AM, Dmitry Olshansky wrote:
>> Static if is certainly NOT an attribute, it doesn't make any sense.
>
> Yes, it does make sense. It was not an accident that the frontend treats
> it as it does, the code to do it was deliberately put there.

With the reason being? I could deliberately put any code anywhere.

> The attributes are all designed to affect a block of code - so are
> version/debug/staticif - why should they be different?

Because they are different constructs?
static if models if-else, so does the version statement BTW (else version). debug doesn't model if-else. I could see *some* common ground between them.

safe/pure/nogc etc. are different in that they all affect symbols and have no conditional clause, *some* of them even have counterparts (consistency? - I do not see any).

This for instance doesn't work:

static if(1):
    int blah;
else
{}

while this does:

static if(1)
    int blah;
else:


Does it make any sense? To me - no, not at all.
Not every decision must be taken on the grounds of making some code in compiler more straightforward.
After all C's #include was so simple to implement and we know where this way leads to.

-- 
Dmitry Olshansky

On 5/29/2014 3:19 PM, Dmitry Olshansky wrote:
> With the reason being?

The same reason you might want to put:

  @nogc:
  ...

at the beginning of a source module instead of:

  @nogc: {
    ...
  }