November 23, 2009
Chad J wrote:
> Don wrote:
>> Chad J wrote:
>>> Sorry I didn't know about Andrei's proposal.  Buried in the NG.
>> I'm surprised about that. It's what all the recent posts were based on!
>>
> 
> Now I'm confused.
> 
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=101110
> 
> The recent posts were in a thread that *I* started.
> 
> Andrei was the first one in on the action:
> 
> Andrei Alexandrescu wrote:
>> Chad J wrote:
>>> So, switch-case statements are a frequent source of nasty bugs.  Fixing
>>> them (well) requires breaking backwards compatibility.
>>>
>>> Any chance this will happen for D2?
>>>
>>> (This is intended as more of a reminder and simple curiosity than a
>>> discussion.)
>> I wish very much that a transferring control flow statement (break,
>> return, goto etc.) is required at the end of each case. Then, the rare
>> case when you want to break through is easy to implement as goto case
>> xxx; and all is good.
>>
>> Walter's answer to that has put me to silence for good. "But I use
>> fall-through all the time!" I then knew the feature will never make it.
>>
>>
>> Andrei
> 
> Agreeable words indeed, but not terribly detailed.  I have to imagine
> you and I are looking at different things.

You're right. I think he reiterated it somewhere in that thread though. But there's been a lot of traffic recently.

> 
>>> Why didn't you just say that Andrei made another proposal and that
>>> you're peeved I didn't use it?
>> I'm not peeved.
>>
> 
> "You've done a patch which completely ignores his proposal, and which
> violates both. "
> 
> "completely ignores" and "violates".  Strong words.  Ya coulda fooled me.

That's only because I had to say the same thing about three different times to try to get you to understand what's wrong with it.
Introducing new syntax that has never been discussed is GUARANTEED to get a patch rejected. Your original patch broke all the rules, quite unnecessarily.

> There's nothing wrong with being peeved ;)

I was just doing you a favour by telling you how to write a patch that's more likely to be accepted. I don't have any personal feelings about the issue or the patch, just sick of wasting my time on something so unimportant.


November 23, 2009
Chad J wrote:
> Don wrote:
>> You've missed the point. Andrei made a proposal for eliminating
>> accidental fallthrough bugs. It didn't involve any new syntax, and
>> changed very little existing code. Anything which violates either of
>> those things has very little chance of acceptance. You've done a patch
>> which completely ignores his proposal, and which violates both.
>>
> 
> Sorry I didn't know about Andrei's proposal.  Buried in the NG.
> 
> Why didn't you just say that Andrei made another proposal and that
> you're peeved I didn't use it?

Guys, guys. I don't even think I made that proposal, I'm pretty sure it has been discussed before around this newsgroup.

Anyway, I think Chad's proposal has not been discussed here before being implemented, which makes it more difficult to accept. On the other hand, the fact that Chad implemented a change to switch means that he has a good understanding of the implementation, meaning he could adjust his patch to implement whichever design we all agree is suitable.


Andrei
November 23, 2009
On 11/22/2009 05:18 PM, Don wrote:
>
> I wasn't. Introducing case xxx!: is the problem.
>

Ok, I'll bite, why is it a problem?

Because it's a new syntax.
Because fallthrough isn't a big enough issue to devote an entire lexical token to.
Because it came out of the blue.
Because instead of overhauling the entire thing and coming up with a new syntax which only executes one of the case blocks, which is what is intended 99.994% of the time, we should make arcane patches to an inherently bad design. No wait..
November 23, 2009
Andrei Alexandrescu wrote:
> 
> Guys, guys. I don't even think I made that proposal, I'm pretty sure it has been discussed before around this newsgroup.
> 
> Anyway, I think Chad's proposal has not been discussed here before being implemented, which makes it more difficult to accept. On the other hand, the fact that Chad implemented a change to switch means that he has a good understanding of the implementation, meaning he could adjust his patch to implement whichever design we all agree is suitable.
> 
> 
> Andrei

Thank you, Andrei.

I'm quite fine with changing the patch or even rewriting it from scratch.  My meager hours are nothing compared to the grief this could save others from.

- Chad
November 23, 2009
Andrei Alexandrescu, el 22 de noviembre a las 17:11 me escribiste:
> Anyway, I think Chad's proposal has not been discussed here before being implemented, which makes it more difficult to accept.

I think the exact opposite. It's much easier to accept (or reject)
something that have an actual implementation. You can talk about something
real, not vaporware. I wish all proposals made here were proposed with
a patch.

Of course that's a lot of work and people usually don't want to make the effort to write a patch if chances are it will be rejected. But if the rules are clear ("your patch can be rejected"), I think you should encourage feature proposal with proof-of-concept patch.

From this thread, I really feel like you're doing the exact opposite. At least that this is my perception.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
ASALTAN, GOLPEAN SALVAJEMENTE A ANCIANA Y LE COMEN LA PASTAFROLA.
	-- Crónica TV
November 23, 2009
Mon, 23 Nov 2009 14:18:05 -0300, Leandro Lucarella wrote:

> Andrei Alexandrescu, el 22 de noviembre a las 17:11 me escribiste:
>> Anyway, I think Chad's proposal has not been discussed here before being implemented, which makes it more difficult to accept.
> 
> I think the exact opposite. It's much easier to accept (or reject) something that have an actual implementation. You can talk about something real, not vaporware. I wish all proposals made here were proposed with a patch.
> 
> Of course that's a lot of work and people usually don't want to make the effort to write a patch if chances are it will be rejected. But if the rules are clear ("your patch can be rejected"), I think you should encourage feature proposal with proof-of-concept patch.

The fact that a patch already exists does not make the design decision any better. If we all started writing crappy, contradicting extensions and Walter had to accept everything, D would quickly sink. There are only a handful of active members in this community that have enough experience and skills to propose any good features at this point of d development cycle.
November 23, 2009
retard, el 23 de noviembre a las 17:34 me escribiste:
> Mon, 23 Nov 2009 14:18:05 -0300, Leandro Lucarella wrote:
> 
> > Andrei Alexandrescu, el 22 de noviembre a las 17:11 me escribiste:
> >> Anyway, I think Chad's proposal has not been discussed here before being implemented, which makes it more difficult to accept.
> > 
> > I think the exact opposite. It's much easier to accept (or reject) something that have an actual implementation. You can talk about something real, not vaporware. I wish all proposals made here were proposed with a patch.
> > 
> > Of course that's a lot of work and people usually don't want to make the effort to write a patch if chances are it will be rejected. But if the rules are clear ("your patch can be rejected"), I think you should encourage feature proposal with proof-of-concept patch.
> 
> The fact that a patch already exists does not make the design decision any better. If we all started writing crappy, contradicting extensions and Walter had to accept everything, D would quickly sink. There are only a handful of active members in this community that have enough experience and skills to propose any good features at this point of d development cycle.

And what I said above doesn't contradict this, on the contrary.

In other OSS projects, almost the *only* way to ask for a feature is providing a patch. Then the feature is discussed (and most of the time discarded). Having a patch only improves the decision making process.

Again, and in case it's hard to understand, I'm not saying the any patch
should be accepted. Even more, I don't think Chad's patched should be
accepted, I also think introducing case !: is a bad idea. I'm just saying
that the patch was mostly turned down because he didn't asked for other
devs permission to make the patch, not because of the quality of the patch
(or the feature) itself. That discourages people to make patches, and
I think that's *really* bad.

Again, that was only my perception, maybe this was not the intention of the people who wrote the messages.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Cuando intenté arrimarle mi brazo
Se puso a hablar de Miller, de Anais Nin y Picasso
Y si osaba intentar robarle un beso
Se ponía a leer de Neruda unos versos
Me hizo mucho mal la cumbiera intelectual
November 23, 2009
Leandro Lucarella wrote:
> retard, el 23 de noviembre a las 17:34 me escribiste:
>> Mon, 23 Nov 2009 14:18:05 -0300, Leandro Lucarella wrote:
>>
>>> Andrei Alexandrescu, el 22 de noviembre a las 17:11 me escribiste:
>>>> Anyway, I think Chad's proposal has not been discussed here before
>>>> being implemented, which makes it more difficult to accept.
>>> I think the exact opposite. It's much easier to accept (or reject)
>>> something that have an actual implementation. You can talk about
>>> something real, not vaporware. I wish all proposals made here were
>>> proposed with a patch.
>>>
>>> Of course that's a lot of work and people usually don't want to make the
>>> effort to write a patch if chances are it will be rejected. But if the
>>> rules are clear ("your patch can be rejected"), I think you should
>>> encourage feature proposal with proof-of-concept patch.
>> The fact that a patch already exists does not make the design decision any better. If we all started writing crappy, contradicting extensions and Walter had to accept everything, D would quickly sink. There are only a handful of active members in this community that have enough experience and skills to propose any good features at this point of d development cycle.
> 
> And what I said above doesn't contradict this, on the contrary.
> 
> In other OSS projects, almost the *only* way to ask for a feature is
> providing a patch. Then the feature is discussed (and most of the time
> discarded). Having a patch only improves the decision making process.
> 
> Again, and in case it's hard to understand, I'm not saying the any patch
> should be accepted. Even more, I don't think Chad's patched should be
> accepted, I also think introducing case !: is a bad idea. I'm just saying
> that the patch was mostly turned down because he didn't asked for other
> devs permission to make the patch, not because of the quality of the patch
> (or the feature) itself. That discourages people to make patches, and
> I think that's *really* bad.
> 
> Again, that was only my perception, maybe this was not the intention of
> the people who wrote the messages.

I understand and agree. One issue we're facing right now is that the publication of the D source is relatively recent and the number of contributors is relatively low. In this context, if we required anyone who ever wants to propose a feature to also provide a patch we'd pretty much kill the traffic on this group. I look forward to the day when that request will become reasonable.

The positive side remains: Chad now knows enough about the implementation to accommodate any change to the design.

At any rate, after having discussed this more with Walter, it looks like the switch semantics is here to stay. He claims to use fall through fairly often (in spite of the mounting evidence to the contrary) and finds the notion that you need to wrote "goto case x;" just before "case x:" completely stupid. I disagree but I also want to carefully pick my fights so I'll leave this matter to others.


Andrei
November 23, 2009
On Mon, Nov 23, 2009 at 11:33 AM, Leandro Lucarella <llucax@gmail.com> wrote:
> I'm just saying
> that the patch was mostly turned down because he didn't asked for other
> devs permission to make the patch, not because of the quality of the patch
> (or the feature) itself. That discourages people to make patches, and
> I think that's *really* bad.

Don may have said that not discussing a change before submitting a patch for it dooms the patch to failure, but I don't think that's true at all.  I think it just means that the chances the patch will solve the problem in a way that is agreeable to those who matter is much smaller.  But if Chad had managed to hit on the magic formula that everyone thought was a great solution, I think the patch would have been accepted (after some inevitable discussion).

In this case, had Chad discussed the matter first, I think he would have quickly found that there was little support for his syntax extension, and he could have saved himself the trouble of implementing it.

--bb
November 23, 2009
On Mon, Nov 23, 2009 at 11:43 AM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> Leandro Lucarella wrote:
>>
>> retard, el 23 de noviembre a las 17:34 me escribiste:
>>>
>>> Mon, 23 Nov 2009 14:18:05 -0300, Leandro Lucarella wrote:
>>>
>>>> Andrei Alexandrescu, el 22 de noviembre a las 17:11 me escribiste:
>>>>>
>>>>> Anyway, I think Chad's proposal has not been discussed here before being implemented, which makes it more difficult to accept.
>>>>
>>>> I think the exact opposite. It's much easier to accept (or reject) something that have an actual implementation. You can talk about something real, not vaporware. I wish all proposals made here were proposed with a patch.
>>>>
>>>> Of course that's a lot of work and people usually don't want to make the effort to write a patch if chances are it will be rejected. But if the rules are clear ("your patch can be rejected"), I think you should encourage feature proposal with proof-of-concept patch.
>>>
>>> The fact that a patch already exists does not make the design decision
>>> any better. If we all started writing crappy, contradicting extensions and
>>> Walter had to accept everything, D would quickly sink. There are only a
>>> handful of active members in this community that have enough experience and
>>> skills to propose any good features at this point of d development cycle.
>>
>> And what I said above doesn't contradict this, on the contrary.
>>
>> In other OSS projects, almost the *only* way to ask for a feature is providing a patch. Then the feature is discussed (and most of the time discarded). Having a patch only improves the decision making process.
>>
>> Again, and in case it's hard to understand, I'm not saying the any patch
>> should be accepted. Even more, I don't think Chad's patched should be
>> accepted, I also think introducing case !: is a bad idea. I'm just saying
>> that the patch was mostly turned down because he didn't asked for other
>> devs permission to make the patch, not because of the quality of the patch
>> (or the feature) itself. That discourages people to make patches, and
>> I think that's *really* bad.
>>
>> Again, that was only my perception, maybe this was not the intention of the people who wrote the messages.
>
> I understand and agree. One issue we're facing right now is that the publication of the D source is relatively recent and the number of contributors is relatively low. In this context, if we required anyone who ever wants to propose a feature to also provide a patch we'd pretty much kill the traffic on this group. I look forward to the day when that request will become reasonable.
>
> The positive side remains: Chad now knows enough about the implementation to accommodate any change to the design.
>
> At any rate, after having discussed this more with Walter, it looks like the switch semantics is here to stay. He claims to use fall through fairly often (in spite of the mounting evidence to the contrary) and finds the notion that you need to wrote "goto case x;" just before "case x:" completely stupid. I disagree but I also want to carefully pick my fights so I'll leave this matter to others.

How would Walter feel about
case continue;
or
continue case;
??

--bb