"with" still sucks + removing features + adding features

bearophile bearophileHUGS at lycos.com
Mon May 18 11:33:29 PDT 2009

Andrei Alexandrescu:

>Yeah, so for the sake of a feature intended to save some minor typing, I'm thrilled to introduce a feature requiring me a ton of typing.<

Please, be serious. You can have the same old behavour with just 2 added chars:
import foo.*;
I have discussed about something like this four times in the past.

> enum DeviceStatus { ready, busy, fail }
> ...
> void process(DeviceStatus status) {
>     final switch (status) {
>     case DeviceStatus.ready:
>        ...
>     case DeviceStatus.busy:
>        ...
>     case DeviceStatus.fail:
>        ...
>     }
> }
> If you then add a new value for DeviceStatus, the final switch
> won't compile.

1) I don't like this idea. I think that normal switches can behave like such final switches.
2) I'd like Walter to ask people before implement features. People here discuss about feature X for a week, that they think it is cool (or maybe even useful!), and then weeks later Walter implements feature Y that no one was asking for. This is not just wrong, it's silly.
3) If you want to add a second kind of switch, then let's add a truly safer one, with no fall-through, etc. We have discussed about this more than one time. See the switch of C#, for example.

>I think it's important to give switch a crack on properly optimizing its code.<

Of course. That's why I was talking about a "built-in syntax". I am sure the compiler doesn't need rocket science to optimize a new syntax to say the same thing. I have done this in the ShedSkin compiler, and it's doable.

>And case a .. b I just explained to Jarrett.<

1) The syntax you talk about isn't intuitive. This is bad.
2) Before introducing new syntax it's MUCH better to discuss it first, because what's intuitive for me can be not intuitive for you. So the best you can do is to ask for several ideas to people, and then use the one that is both logically sound, and intuitive for most people. This is how Python syntax is designed. And Python3 has less warts than most languages around.
3) In the past I have discussed how Ruby, Chapel and other languages solve this problem. A solution is to use a .. #b to denote that b is inclusive. You may not like this idea (and I am not sure I like it much), but it doesn't look so much worse than case a: .. case b:

Thank you uncovering part of the future work of Walter, giving people 1 chance to cach design mistakes before they happen.


More information about the Digitalmars-d mailing list