July 13, 2005
Nick wrote:
> In article <db12ll$17tq$1@digitaldaemon.com>, Ben Hinkle says...
> 
>>* more intuitive for most users (ie - those not assuming AAs are stl::map)
>>* more like Java, C#, Ruby (which return null and only work for classes) and Python (which errors)
>>* means regular rvalue lookup does not modify the array which means reading is thread-safe
>>* consistent with dynamic and static arrays where requesting a value not in the array throws 
> 
> 
> I, for one, agree with you. It can also help catch lots of bugs, such as typos,
> ie:
> 
> somelist["height"] = 10;
> ..
> int height = somelist["heigth"]; // Should complain rather than return zero

If that is a constant, it should be stored in one.  In cases where it is computed or passed as a parameter it will already be in a variable.

In any case, I don't think Walter should limit the capabilities of the language based around possible programmer typos.

-DavidM

July 13, 2005
In article <db302m$629$2@digitaldaemon.com>, David Medlock says...

[snip]

>In any case, I don't think Walter should limit the capabilities of the language based around possible programmer typos.

And so should he change it to allow "if (expr);"  and "if (a=b)" ?


July 14, 2005
sq wrote:
> In article <db302m$629$2@digitaldaemon.com>, David Medlock says...
> 
> [snip]
> 
> 
>>In any case, I don't think Walter should limit the capabilities of the language based around possible programmer typos.
> 
> 
> And so should he change it to allow "if (expr);"  and "if (a=b)" ?
> 
> 
Both are syntactical lint-like check built into the compiler.

Nothing in the spec disallows the first one, its not allowed in Walter's implementation.

I can prove the second is lint-checking too:

  bool b = ( a = true );
  if ( a = true ) writefln("Hello");

on the first line ( a = true ) evaluates to a boolean.
On the second line the same expression does not....

Your example is syntax, the discussion is semantics.

-DavidM
1 2 3 4
Next ›   Last »