August 02, 2007
Bruno Medeiros wrote:
> BCS wrote:
>>> -------------------------
>>>
>>> 6) It can be useful a way to create an empty associative array with something like:
>>> new int[char[]]();
>>>
>>
>> assigning null to an aa results in an empty aa, I'm not sure if it clear other references to it though.
>>
> 
> Are you sure of that? It seems that at least for AA's, empty arrays are different than null arrays:
> 
>     int[char[]] b;           writefln(b is null); // true
>     writefln(b == null); // true

Huh.  So equality comparisons with null work for AAs but crash with objects?


Sean
August 02, 2007
Sean Kelly a écrit :
> bearophile wrote:
>> 4) Python defines < <= == != >= > among dicts (AAs) too:
>>
>>>>> {1:2, 2:3} == {1:2, 2:3}
>> True
>>>>> {1:3, 2:3} == {1:2, 2:3}
>> False
>>>>> {1:2, 2:3} < {1:2, 2:3}
>> False
>>>>> {1:2, 2:3} > {1:2, 2:3}
>> False
>>>>> {1:2, 2:3, 3:1} > {1:2, 2:3}
>> True
>>>>> {1:2, 2:3, 3:1} > {1:2, 2:3, 4:1}
>> False
>>>>> {1:2, 2:3, 3:1} < {1:2, 2:3, 4:1}
>> True
>>
>> It seems not even the quite useful opEquals among AAs is defined yet in dmd V1.015:
>> assert(['a':2, 'b':3] == ['a':2, 'b':3]);
> 
> Seems handy, and more consistent than the current behavior.

While I agree with ==, I'm a bit puzzled by '<': is-it always possible to order keys and values?
And if it isn't possible what will happen, a compile time error?


>> 7) From the FAQ: >Many people have asked for a requirement that there be a break between cases in a switch statement, that C's behavior of silently falling through is the cause of many bugs. The reason D doesn't change this is for the same reason that integral promotion rules and operator precedence rules were kept the same - to make code that looks the same as in C operate the same. If it had subtly different semantics, it will cause frustratingly subtle bugs.<
>>
>> I agree with both points of view. My idea: calling this statement differently (like caseof) instead of "switch" (like in Pascal), so you can change its semantics too, removing the falling through (you may use the Pascal semantic too).
> 
> It's a good idea, but I actually like the fall-through behavior.  I use it regularly.

Sure, fall-through behaviour is useful sometimes, but it shouldn't be the default.. Pascal semantic isn't good enough as it didn't have a way to allow fall-through but this could be added..

renoX


August 02, 2007
Jascha Wetzel <[firstname]@mainia.de> Wrote:

> Bill Baxter wrote:
> > Or you need to have a slick IDE that parses everything and figures out for you where various symbols are coming from.
> 
> today's programming practice (and language design, as far as it's
> concerned) should be able to assume proper tools. many things like this
> can be tackled with semantics-aware features for editors. another
> example are complex naming conventions that emphasize type or scope of
> variables (like hungarian notation).
> what these things have in common is, that they make code less readable
> by including information that can be obtained in different ways.
> readability depends on the reader. the more familiar you are with the
> code, the less readable it becomes by additional information. the same
> holds true if you are only interested in the general function.
> 
> i think, that the more real code looks like pseudo code, the better. i often start programming by writing down pseudo code in the editor. it's easier to mess around with and it isn't as officially separate like an upfront pen-and-paper design phase. after i'm happy with the pseudo code, i add the remaining detail. over and over i'm impressed about how little detail i need to add to make it valid D code. the closer it stays to the pseudo-code stage, the easier it is to maintain and refactor. therefore keeping it that way should be a good thing. if additional information can be gathered from an edit-time parser, it shouldn't be in the code.
> 
> ...sorry for the rant ;)

Sorry to veer so far offtopic, but you've just described one the main reasons I don't like Java's concept of checked exceptions (ie, all of that messy "throws" nonsense). (The other reason is it makes me feel like I've stepped right back into C's world of header file madness.)
August 03, 2007
Sean Kelly wrote:
> Bruno Medeiros wrote:
>> BCS wrote:
>>>> -------------------------
>>>>
>>>> 6) It can be useful a way to create an empty associative array with something like:
>>>> new int[char[]]();
>>>>
>>>
>>> assigning null to an aa results in an empty aa, I'm not sure if it clear other references to it though.
>>>
>>
>> Are you sure of that? It seems that at least for AA's, empty arrays are different than null arrays:
>>
>>     int[char[]] b;           writefln(b is null); // true
>>     writefln(b == null); // true
> 
> Huh.  So equality comparisons with null work for AAs but crash with objects?
> 
> 
> Sean

Seems so, just as you don't need to allocate an AA to use it, it is done automatically if the AA is null.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
August 03, 2007
> 7) From the FAQ: 

> Many people have asked for a requirement that there be a break
> between cases in a switch statement, that C's behavior of
> silently falling through is the cause of many bugs.
> The reason D doesn't change this is for the same reason that
> integral promotion rules and operator precedence rules were
> kept the same - to make code that looks the same as in C
> operate the same. If it had subtly different semantics, it
> will cause frustratingly subtle bugs.

> I agree with both points of view. My idea: calling this
> statement differently (like caseof) instead of "switch"
> (like in Pascal), so you can change its semantics too,
> removing the falling through (you may use the Pascal
> semantic too).

Sorry to hijack your point here, but this got me thinking:

Why not use "continue" for seeping through to the next case statement? DMD could then complain if a case does not end with break/continue/goto/return and silently insert a assert(0) before each case (the way it does for functions that return a value.)

L.
August 03, 2007
Lionello Lunesu wrote:
>> 7) From the FAQ: 
> 
>> Many people have asked for a requirement that there be a break
>  > between cases in a switch statement, that C's behavior of
>  > silently falling through is the cause of many bugs.
>  > The reason D doesn't change this is for the same reason that
>  > integral promotion rules and operator precedence rules were
>  > kept the same - to make code that looks the same as in C
>  > operate the same. If it had subtly different semantics, it
>  > will cause frustratingly subtle bugs.
> 
>> I agree with both points of view. My idea: calling this
>  > statement differently (like caseof) instead of "switch"
>  > (like in Pascal), so you can change its semantics too,
>  > removing the falling through (you may use the Pascal
>  > semantic too).
> 
> Sorry to hijack your point here, but this got me thinking:
> 
> Why not use "continue" for seeping through to the next case statement? DMD could then complain if a case does not end with break/continue/goto/return and silently insert a assert(0) before each case (the way it does for functions that return a value.)

Doesn't

for (c;;) {
  switch (c) {
  case 'a': continue;
  case 'b': break;
  }
}

already have a meaning?
August 03, 2007
> Doesn't
> 
> for (c;;) {
>    switch (c) {
>    case 'a': continue;
>    case 'b': break;
>    }
> }
> 
> already have a meaning?

That always bothered me: break and continue both have similar meanings in every place they're used (in loops), except if there's a switch statement, where suddenly break no longer works to break the loop but continue does. I'd very much like to see continue mean fall-through, but if that's not an option, making an unlabeled continue in a switch an error would help increase orthagonality.
August 05, 2007
Don Clugston wrote:
> Lionello Lunesu wrote:
>>> 7) From the FAQ: 
>>
>>> Many people have asked for a requirement that there be a break
>>  > between cases in a switch statement, that C's behavior of
>>  > silently falling through is the cause of many bugs.
>>  > The reason D doesn't change this is for the same reason that
>>  > integral promotion rules and operator precedence rules were
>>  > kept the same - to make code that looks the same as in C
>>  > operate the same. If it had subtly different semantics, it
>>  > will cause frustratingly subtle bugs.
>>
>>> I agree with both points of view. My idea: calling this
>>  > statement differently (like caseof) instead of "switch"
>>  > (like in Pascal), so you can change its semantics too,
>>  > removing the falling through (you may use the Pascal
>>  > semantic too).
>>
>> Sorry to hijack your point here, but this got me thinking:
>>
>> Why not use "continue" for seeping through to the next case statement? DMD could then complain if a case does not end with break/continue/goto/return and silently insert a assert(0) before each case (the way it does for functions that return a value.)
> 
> Doesn't
> 
> for (c;;) {
>   switch (c) {
>   case 'a': continue;
>   case 'b': break;
>   }
> }
> 
> already have a meaning?

I can't think of any other case where this problem would show (aside from other looping statements, so the fix is the same).  Since this is probably not an overly common case (I've done it myself, but not very often), I don't think writing a label on the loop would be a big deal. I could live with fall-thru-by-continue.  Maybe if looping statements had a shorthand form for labeling, it could be even cleaner...

for loop (c;;) {
  switch (c) {
    case 'a': continue loop;
    case 'b': break loop;
  }
}

-- Chris Nicholson-Sauls
August 06, 2007
Chris Nicholson-Sauls wrote:
> Don Clugston wrote:
>> Lionello Lunesu wrote:
>>>> 7) From the FAQ: 
>>>
>>>> Many people have asked for a requirement that there be a break
>>>  > between cases in a switch statement, that C's behavior of
>>>  > silently falling through is the cause of many bugs.
>>>  > The reason D doesn't change this is for the same reason that
>>>  > integral promotion rules and operator precedence rules were
>>>  > kept the same - to make code that looks the same as in C
>>>  > operate the same. If it had subtly different semantics, it
>>>  > will cause frustratingly subtle bugs.
>>>
>>>> I agree with both points of view. My idea: calling this
>>>  > statement differently (like caseof) instead of "switch"
>>>  > (like in Pascal), so you can change its semantics too,
>>>  > removing the falling through (you may use the Pascal
>>>  > semantic too).
>>>
>>> Sorry to hijack your point here, but this got me thinking:
>>>
>>> Why not use "continue" for seeping through to the next case statement? DMD could then complain if a case does not end with break/continue/goto/return and silently insert a assert(0) before each case (the way it does for functions that return a value.)
>>
>> Doesn't
>>
>> for (c;;) {
>>   switch (c) {
>>   case 'a': continue;
>>   case 'b': break;
>>   }
>> }
>>
>> already have a meaning?
> 
> I can't think of any other case where this problem would show (aside from other looping statements, so the fix is the same).  Since this is probably not an overly common case (I've done it myself, but not very often), I don't think writing a label on the loop would be a big deal.

That's fine. The issue is that it would silently break existing code.
August 06, 2007
Don Clugston wrote:
> Chris Nicholson-Sauls wrote:
>> Don Clugston wrote:
>>> Lionello Lunesu wrote:
>>>>> 7) From the FAQ: 
>>>>
>>>>> Many people have asked for a requirement that there be a break
>>>>  > between cases in a switch statement, that C's behavior of
>>>>  > silently falling through is the cause of many bugs.
>>>>  > The reason D doesn't change this is for the same reason that
>>>>  > integral promotion rules and operator precedence rules were
>>>>  > kept the same - to make code that looks the same as in C
>>>>  > operate the same. If it had subtly different semantics, it
>>>>  > will cause frustratingly subtle bugs.
>>>>
>>>>> I agree with both points of view. My idea: calling this
>>>>  > statement differently (like caseof) instead of "switch"
>>>>  > (like in Pascal), so you can change its semantics too,
>>>>  > removing the falling through (you may use the Pascal
>>>>  > semantic too).
>>>>
>>>> Sorry to hijack your point here, but this got me thinking:
>>>>
>>>> Why not use "continue" for seeping through to the next case statement? DMD could then complain if a case does not end with break/continue/goto/return and silently insert a assert(0) before each case (the way it does for functions that return a value.)
>>>
>>> Doesn't
>>>
>>> for (c;;) {
>>>   switch (c) {
>>>   case 'a': continue;
>>>   case 'b': break;
>>>   }
>>> }
>>>
>>> already have a meaning?
>>
>> I can't think of any other case where this problem would show (aside from other looping statements, so the fix is the same).  Since this is probably not an overly common case (I've done it myself, but not very often), I don't think writing a label on the loop would be a big deal.
> 
> That's fine. The issue is that it would silently break existing code.

Okay, I'll grant you that.  Maybe require the 'switch' keyword after the continue?  Or else require a label on the switch... but then continues start acting slightly different from breaks.

No easy way out, it seems.

-- Chris Nicholson-Sauls