"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:bqac81$2rl3$1@digitaldaemon.com...
> E.g. if one knows that a conditional on which execution path depends is necessarily zero, then one could either eliminate checks, or add an assert(var==0), which should be treated by a code analyzer as if variable was just assigned zero!

You're right that one advantage to having assertions as part of the syntax is that the optimizer can potentially make use of the additional information.

Walter, I just wanted to weigh in here.  Your current design (implicit default throws and exception) is, IMHO, a Good Thing.

Having the programmer add
	default: assert(0);
is even better.

Thus, I would argue (I know, you hate warnings, but hear me out) that a warning that explicitly states you are adding the implicit-throw-on-default is a good idea.  It makes the C-porting task easier, and leads people toward better programming practice.

I've had a hard time reading this thread. Instead of a discussion, this has more looked like Walter is getting an awful lot of flack for not revamping case functionality.

I think that if a language implements exceptions, then with it goes inseparably the feature that whatever the programmer has not thought of (i.e. not caught), at least the runtime will offer a graceful and informative exit.

In that same spirit, running off the end of functions, or not having a default part in a case structure, are things the programmer has not "thought of". So these should cause a runtime exception, period.

If that is intentional (as in "we _know_" this'll never happen), then it is a small thing to inform the compiler that this is the case. Also, this informs the next programmer about our intentions, instead of having him think that we're just lazy SOBs.

Breaks in case statements exist because it is customary to have both several different cases be handled by the same code, and also because it is usual that one case only does a one-liner, the rest of which is the same as some other case. Here the missing break turns very useful.

Many things in D come from C(++), and many programmers will have
to work both in D and C(++), at least in the immediately foreseeable
future. Introducing gratuituos differences in the most basic things
would only make their life hard. Since the motivations presented
here (for making the changes in D) have not been able to show any
major advantages, I think we should let this issue rest for now.

(No flames for the following, please:) The fervor with which people have argued for not having to write a couple extra words, has made me think that maybe these guys do not do touch typing. I think such tings should not be permitted to influence the design of a serious language for professional programming.

Even Bjarne Stroustrup has admitted that they made some changes to the language so that it would be "easier to write, in this (or that) particular context", and that some of these changes became dragstones and were regretted later. One excellent example would be declaring complicated pointer variables.

Sorry to be obtuse, but I don't glean what your position is? C/C++ status quo, Walter's no-default exception, compiler-errors on any implicit parts?



"Georg Wrede" <Georg_member@pathlink.com> wrote in message news:bqd1l6$el6$1@digitaldaemon.com...
>
> I've had a hard time reading this thread. Instead of a discussion, this has more looked like Walter is getting an awful lot of flack for not revamping case functionality.
>
> I think that if a language implements exceptions, then with it goes inseparably the feature that whatever the programmer has not thought of (i.e. not caught), at least the runtime will offer a graceful and informative exit.
>
> In that same spirit, running off the end of functions, or not having a default part in a case structure, are things the programmer has not "thought of". So these should cause a runtime exception, period.
>
> If that is intentional (as in "we _know_" this'll never happen), then it is a small thing to inform the compiler that this is the case. Also, this informs the next programmer about our intentions, instead of having him think that we're just lazy SOBs.
>
> Breaks in case statements exist because it is customary to have both several different cases be handled by the same code, and also because it is usual that one case only does a one-liner, the rest of which is the same as some other case. Here the missing break turns very useful.
>
> Many things in D come from C(++), and many programmers will have
> to work both in D and C(++), at least in the immediately foreseeable
> future. Introducing gratuituos differences in the most basic things
> would only make their life hard. Since the motivations presented
> here (for making the changes in D) have not been able to show any
> major advantages, I think we should let this issue rest for now.
>
> (No flames for the following, please:) The fervor with which people have argued for not having to write a couple extra words, has made me think that maybe these guys do not do touch typing. I think such tings should not be permitted to influence the design of a serious language for professional programming.
>
> Even Bjarne Stroustrup has admitted that they made some changes to the language so that it would be "easier to write, in this (or that) particular context", and that some of these changes became dragstones and were regretted later. One excellent example would be declaring complicated pointer variables.
>
>

Walter wrote:
> You're right that one advantage to having assertions as part of the syntax is that the optimizer can potentially make use of the additional information.

I definately didn't mention the optimizer. What i meant is that
assertion is a semantic guarantee, which may be very important to the
code flow analysers, such as the one which makes sure that a function
always retuns. So that if an analyser says that there is some execution
path which doesn't return - it needn't place an assertion there, instead
the programmer may place an assertion which makes sure that this code
path never enters, which should be enough to keep the complaining
analyser quite, and would make program flow more explicit.

Let me also quote Roberto Mariottini, since his idea is of a similar nature:

> BTW, what about user defined enum? Can the compiler know whether all enum constants are used inside a switch, and signal to the programmer
> when some are missing and there is not a default?

Even enum being stored within an int, this information translates into
an implicit assertion (i==enumval1)||(i==enumval2)||(... which need not
be generated in target code, but such information can be worked in by
analysers as such.

I'm probably bad at expressing my thoughts today, so i'll try to
formulate it more thoroughly and post up some other time.

This branch also goes somewhat off the thread topic, which was about
switch. My opinion is that i completely agree with status quo which
guards against unintended misuse very well, but i also find it an
interesting option for a switch to requiere a default case, unless the
code analyser could prove that such a case cannot happen. I would also
vote for a requierement of explicit continue statement, which would give
some symmetry with loops, but it may not be an option to you...

-eye

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:bqdqmg$1hen$1@digitaldaemon.com...
> Walter wrote:
> > You're right that one advantage to having assertions as part of the syntax is that the optimizer can potentially make use of the additional information.
> I definately didn't mention the optimizer. What i meant is that assertion is a semantic guarantee, which may be very important to the code flow analysers,

Well, that's just what an optimizer is: a code flow analyzer. <g>

> such as the one which makes sure that a function
> always retuns. So that if an analyser says that there is some execution
> path which doesn't return - it needn't place an assertion there, instead
> the programmer may place an assertion which makes sure that this code
> path never enters, which should be enough to keep the complaining
> analyser quite, and would make program flow more explicit.

You've just described the general idea of how optimizers work.

> Let me also quote Roberto Mariottini, since his idea is of a similar
nature:
>
> > BTW, what about user defined enum? Can the compiler know whether all enum constants are used inside a switch, and signal to the programmer when some are missing and there is not a default?
>
> Even enum being stored within an int, this information translates into
> an implicit assertion (i==enumval1)||(i==enumval2)||(... which need not
> be generated in target code, but such information can be worked in by
> analysers as such.

Even if all the enum values are accounted for, it's certainly possible the user cast some other value into the enum type.

> This branch also goes somewhat off the thread topic, which was about switch. My opinion is that i completely agree with status quo which guards against unintended misuse very well, but i also find it an interesting option for a switch to requiere a default case, unless the code analyser could prove that such a case cannot happen. I would also vote for a requierement of explicit continue statement, which would give some symmetry with loops, but it may not be an option to you...

Part of my reluctance to do that is implict fallthrough just has never been an issue for me in 25 years of programming. But the implicit default:break; has bitten me many times!

> Part of my reluctance to do that is implict fallthrough just has never
been
> an issue for me in 25 years of programming. But the implicit
default:break;
> has bitten me many times!

I can honestly say that neither issue has hurt me once in, say, the last five years. But what've either of our cat's whiskers got to do with it. There aren't many people who spend as much time as we on the keyboard - lucky bleeders! - so my question is: do you want your language to be a desirable option only for those who've been bitten for hard enough and long enough in older curmudgeonlier languages. There aren't that many of us left; most have slothed off into middle management by now.

Surely you want to appeal to younger programmers. Since universities are not teaching much worth absorbing these days, why not build things into your language that help people who are of intermediate level, rather than just doing the bits you deem are needed for you and those like you(/us)?

1. If every aspect of switch is explicit and compile-time, how many users of
D will be hurt? 0
2. If things remain implicit and, worse, there is runtime handling of
code-time errors, how many users of D will be hurt? Probably about 20-40%
now. Probably about 90-95% of the eventual target user base.

If I'm wrong about this, can someone please tell me. I don't want to hear about any individual wants personally, we've already gone through that already. (Personally, I'd rather have it precisely have the semantics of C's switch, but I'd rather have D robust and successful than have to type a few less keystrokes.)

Just point out where I'm wrong with these projections. (Notwithstanding the inherent inaccuracies in the precise numbers).

Matthew

In article <bqdjvu$1805$2@digitaldaemon.com>, Matthew Wilson says...
>
>Sorry to be obtuse, but I don't glean what your position is? C/C++ status quo, Walter's no-default exception, compiler-errors on any implicit parts?

(I was aspiring to transcend the current issues themselves, but what the heck.) Walter's no-default exception.

I'm thinking of a couple of different situations here. First of all, if D is your first language and you're just learning to use the switch statement, then you normally write the cases you know can happen, but leave the default out (since you 'covered all cases'). If that is ok, then no compiler warning or error. Well, the day comes when you didn't cover all cases, and then there will be a runtime exception.

Now, the same thing happens with uncaught exceptions. Most of the time
your new programs compile and run fine, but then there's the (say
file not found) exception, all of a sudden. So you learn to cover your
bases by taking care of also other than the obvious situations. By this
process, you learn the language (and programming, as such) in a nice
and efficient, natural way.

Second, if you already are a (good) programmer, then you just have all your cases covered. Or, your functions just don't run off the end when you don't intend it. In this case all is fine. If, OTOH you are a 'bad programmer', then that happens to you all the time. Then you learn by mistake (which is a way of life for such people anyhow), until you either get it, or become a marketing person instead.  ;-)

If it were obligatory to write the default statement, then these latter folks would just learn that that is something that has to be there, and obviously the line would be 'default: break;'. When their programs don't work the way they expect, then they have a very hard time finding out why. And since the compiler couldn't warn or error about this, the only way is to figure out why it acts other than we wished.

Making the default case obligatory therefore achieves nothing. But making it 'entirely non-obligatory' doesn't either. (I.e., not causing a runtime exception.)

Of course it is embarrassing if a professionally developed program suddenly quits on a no-default exception. But worse is just running off the end with no warning. It's like sweeping your crap under the rug.

The rant about touch typing was (among other things) for the guys who wanted an implicit break in every case. Sure, it's nice to save ink, but the pros of it don't outweigh the cons.

Matthew Wilson wrote:
>>Have to agree here, I rareley ( never ? ) use exceptions , and dont like
>>them being thrown without my knoweldge / consent.
> 
> 
> Exactamundo, my friend.
> 
> Exceptions are great for somethings, including actual serious/fatal errors,
> or when doing stuff like deep-level parsing.
> 
> Where they are absolutely not appropriate - and I can't believe this is even
> a discusson - is a runtime report of a code-time mistake!!
> 

Sounds like it is calling for a compiler check to me.  I don't mind if the
switch statement REQUIRES a default statement--as long as the compiler reports
the problem.

Following is Walters reasoning why the default checking can't be done at
compile time.

The thing is that we should either make default required all the time--which
is an easy compile-time check--or follow normal switch semantics.  Otherwise
you will run into folks who only want to run some processing in one of a few
cases, but ignore all other cases, and wonder why there is some sort of runtime
exception being thrown.

If you still want something that is runtime checked for these types of things,
perhaps make it a feature of compiling with debug info in place that a message
would be output to the system error stream with enough debug info to know a)
what the value of the variable was, b) where the problem occurred.

That way, there is enough information not only to know something is up, but to
intelligently decide if it is really a problem or not.

Walter wrote:

> "Matthew Wilson" <matthew.hat@stlsoft.dot.org> wrote in message
> news:bq65gu$2n8o$1@digitaldaemon.com...
> 
>>>Have to agree here, I rareley ( never ? ) use exceptions , and dont like
>>>them being thrown without my knoweldge / consent.
>>
>>Exactamundo, my friend.
>>
>>Exceptions are great for somethings, including actual serious/fatal
> 
> errors,
> 
>>or when doing stuff like deep-level parsing.
>>
>>Where they are absolutely not appropriate - and I can't believe this is
> 
> even
> 
>>a discusson - is a runtime report of a code-time mistake!!
> 
> 
> There's no way to detect the error at compile time. What it's for is when
> one has:
> 
> #1
>     switch (x)
>     {
>         case 1: ...
>         case 2: ...
>         case 3: ...
>     }
> 
> and then one day x has the value 4. In C, there's an implicit default:break;
> inserted when no default is explicitly supplied. But in my experience
> coding, debugging my own mistakes, and fixing other peoples' code, the
> implicit default break is almost always the WRONG thing to happen, and then
> something unexpected happens as a result (i.e. crash, data corruption,
> etc.). When I see C code like that, and can ask the author, the intention is
> that x will always be 1, 2 or 3 and NEVER anything else. That's why he wrote
> the switch that way. That's ok, but then the maintenance programmer adds a
> feature where x is 4, updates all the switch statements accordingly, but
> inevitably misses one in the 100,000 line program he's revising. Even if the
> original coder INTENDED to make use of the implicit default:break;, it has
> that distinct odor of a bug, and so I flag it in code reviews. And in my
> experience, it was never intended.
> 
> For years, I've advocated 'defensive programming' in C by making it explicit
> that the default case can never happen with:
> 
> #2
>     switch (x)
>     {
>         case 1: ...
>         case 2: ...
>         case 3: ...
>         default:
>             assert(0);
>     }
> 
> This is the normal practice in my own code. There are 3 situations to deal
> with, the above one, and:
> 
> #3
>     switch (x)
>     {
>         case 1: ...
>         case 2: ...
>         case 3: ...
>         default:
>             break;
>     }
> 
> and:
> 
> #4
>     switch (x)
>     {
>         case 1: ...
>         case 2: ...
>         case 3: ...
>         default:
>             do something
>             break;
>     }
> 
> What D does is make it easy to ensure that all the bases are covered by
> generating #2 if a default is not supplied. You're not going to get caught
> with a random crash from forgetting to deal with a case. The compiler cannot
> do this at compile time because it has no way of determining all possible
> values x can take. In that way, it's similar to run time array bounds
> checking. The only other way of doing this with a hope of robustness is to
> *require* an explicitly written default statement for every switch. This
> would certainly be a valid language strategy, but I don't really want to be
> nagged by the compiler to insert a default:assert(0); when I know darn well
> that x can never be 4 <g>.
> 
>