March 02, 2004
larry cowan wrote:
> Ok, guess I misread your intentions for base level assign.
> So "s + r" would have base r

Correct.

> falling into illegal.

Illegal to do what with, exactly?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.
March 02, 2004
Ilya Minkov wrote:

> Mark T wrote:
> 
>> Why not fix some of the problems C has that forced lint-like tools to be created in the first place?

It does.  Near the end of the overview:

"D compilers will not generate warnings for questionable code. Code will either be acceptable to the compiler or it will not be. This will eliminate any debate about which warnings are valid errors and which are not, and any debate about what to do with them. The need for compiler warnings is symptomatic of poor language design."

And as I said before,
"If you're going to stay true to your 'no warnings' philosophy, you should make them errors, rather than getting rid of them altogether."

> Because we need to avoid too much change as compared to C semantics.

According to the FAQ, the point is "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."

Several things in C are already illegal in D.  A compiler error would not constitute a "frustratingly subtle bug".  Quite the opposite, it would force the programmer to fix what would otherwise lead to a frustratingly subtle bug in itself.

<snip>
> Ada is quite another kind of language. D would not be a C succesor any longer if it went that way. Not that i would be against it, but it doesn't seem possible, targetting wide audience.
<snip>

Define "C successor".  You're not thinking of the word "superset", are you?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.
March 03, 2004
>
>> Because we need to avoid too much change as compared to C semantics.
>
>According to the FAQ, the point is "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."
>
>Several things in C are already illegal in D.  A compiler error would not constitute a "frustratingly subtle bug".  Quite the opposite, it would force the programmer to fix what would otherwise lead to a frustratingly subtle bug in itself.

totally agree - why bring forward the stuff in C that is pretty much wrong except for operator precedence which has known problems, but would confuse people if changed

besides I thought Walter originally wanted C-style syntax not necessarily all the semantics (i.e. baggage) otherwise let's just use C++

Since Java and C# are now popular C-style syntax languages, what did they do to correct some C-isms?

One fix I can think of:

if ( boolean_expression )
in Java boolean_expression can't be an "int" it has to be a Boolean variable or
expression






March 04, 2004
Mark T wrote:

<snip>
> totally agree - why bring forward the stuff in C that is pretty much wrong
> except for operator precedence which has known problems, but would confuse
> people if changed
> 
> besides I thought Walter originally wanted C-style syntax not necessarily all
> the semantics (i.e. baggage) otherwise let's just use C++

Totally agree.  I particularly think carrying forward the switch fall-through was silly.  Like, no frustratingly subtle bug can possibly arise from requiring that the point immediately between a statement and a case label be either unreachable, or marked explicitly as a fallthrough by some means.  Or by having discarded it in favour of something more structured (like what I proposed a while back) in the first place.

After all, if we really are trying to stop subtle bugs by people used to C, why the exception on no matching case or default?

> Since Java and C# are now popular C-style syntax languages, what did they do to
> correct some C-isms?
> 
> One fix I can think of:
> 
> if ( boolean_expression ) in Java boolean_expression can't be an "int" it has to be a Boolean variable or
> expression 

Java also made some warnings errors, like:
- Possible use of 'qwert' before assignment
- Code has no effect (at least in the most basic instances)

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.
March 06, 2004
Sean Kelly wrote:

[...]
> if doing this at a more basic level (like you suggested with policies)
> would break anything.

I retreat from my suggestions of policies. This might lead to system isles.

So long.
March 22, 2004
Walter wrote:

> At issue is whether implicit narrowing conversions should be allowed
[...]

Implicit or explicit does not matter when the term "narrowing
conversion" stays undefined, because no competing compiler will be able to
mimic the unknown behaviour of dmd.

So long!

1 2 3 4 5 6 7
Next ›   Last »