On 9/28/16 7:17 AM, pineapple wrote:
These were not documented as a requirement anywhere that I saw. I'd have been happy to comply, if I had known this was the practice.
Yah, we're also learning the ropes. Bear with us - this is one of the first DIPs using the new flow.
I don't know enough about how D is compiled to speak meaningfully about implementation details.
I'll formalize this in DIP guide, but some level of implementation discussion is necessary - the more, the better. It has happened in the past (in various languages) that things that seemed sensible were proposed and partially implemented without a clear handle on implementation issues. It would improve the DIP a lot if you collaborated with somebody fluent with implementation issues.
I am clearly not the only one who's convinced this is a useful feature. I welcome you or anyone else who can more effectively express the idea to make their own contributions to the DIP.
If catch and finally don't continue the scope of try, then neither should else.
Then I'd say the DIP should discuss the relative advantages and disadvantages compared to the incarnations in other languages. My understanding is it is important for the "else" branch to continue work initiated in the "try" branch. How well does the feature fare without this amenity? It's the kind of question the DIP should address.
That said, it might be preferable if they all did continue try's scope. But this would be a distinct and separate change.
The short answer is that will never happen.
* The "Breaking changes" section should include how the following change in semantics would be addressed. Consider: try if (expression) try { ... } catch (Exception) { ... } else { ... } finally { ... } This code is currently legal and binds the "else" clause to the "if" and the "finally" to the first "try". The proposed feature will bind the "else" and the "finally" to the second try and then probably fail to compile because there is no "catch" or "finally" matching the first "try".This possibility hadn't occurred to me. Is that really legal? If so, I'd argue the old behavior should be maintained and also that people shouldn't write such ambiguous code.
For a DIP to be successful, its authors need to be fluent with syntactical matters and be able to enumerate them and how they are supposed to be handled ("else" also works with "static if", "version", and since DIP 1002 itself, other "try" statements).
Andrei
