http://d.puremagic.com/issues/show_bug.cgi?id=3889



--- Comment #10 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-08-14 18:40:04 PDT ---
My point is that if it's too late to change this, then there's no point in having the enhancement request. And I'd be very surprised if you could take Walter into it at this point. I'm not judging whether the enhancement request would be valuable. I'm merely saying that at this point, I think that it's too late to make the changes for D2.

And as to enhancement requests sitting around until it becomes too late to change things,

1. As soon as TDPL came out, it became too late to change a lot of stuff. If there's enough value in changing it, it can still be change, but the bar is much higher.

2. If you want changes to be made, you're going to need to discuss them in the newsgroup and push for them to happen. You may also need to implement them (or get someone else to implement them) and create a pull request. Enhancement requests that just sit in bugzilla are likely to just sit in bugzilla and go nowhere. For the most part, for them to occur, there needs to be a push for it, and a very good set of arguments as to why the change needs to be made.

3. Given how many suggestions you're always making, I would suggest that pick which battles you intend to fight. If you're only pushing for a couple of enhancement requests, then you're a lot more likely to get them accepted then if you're pushing for dozens of them. I don't know how many enhancement requests you have sitting in bugzilla or how many you've mentioned in the newsgroup, but you bring up new ones often enough that they risk becoming noise that doesn't get paid attention to by any of the people who could actually make them happen. The language is supposed to be essentially stable at this point, and there just isn't man power to implement a deluge of enhancement requests. So, pick whichever ones matter to you the most and push for them to get implemented, but don't keep coming up with new enhancement requests all the time. You obviously can if you want to, but a large portion of them are just going to get ignored.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3889


Brad Roberts <braddr@puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |braddr@puremagic.com


--- Comment #11 from Brad Roberts <braddr@puremagic.com> 2011-08-14 18:52:45 PDT ---
Careful Jonathan, you're talking as if D2 is the end of the development roadmap for D as a language.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3889



--- Comment #12 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-08-14 19:15:02 PDT ---
There's plenty more that needs to be done for D2 to be properly stable and "complete." And even once it's fully stable, we can make changes which don't break backwards compatibility. But I don't think that we're going to be wanting to make much in the way of breaking changes at that point. Certainly, any such changes will have to have very good reasons for being made.

However, we _are_ past the stage where the language is fully malleable. It's supposed to be essentially stable with changes made as necessary to stabilize it and make it so that all of the existing features are properly usable. We're not looking to add or alter features left and right anymore. In that sense, D2 _is_ reaching the end of its development roadmap. At this point, most of the work is going towards stabilizing and completing existing features, not adding new ones.

But regardless of that, my point is that Bearophile is constantly asking for language changes, and the fact that he's constantly asking for them means that we couldn't possible implement them all even the language were still completely malleable. He can't expect us to implement them all. And the fact that he asks for so many means that each of them tends to get lost. It may be that most of them are quite valuable and excellent ideas, but if he wants them to be paid attention to, he's going to need to focus on the more important ones.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3889



--- Comment #13 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-08-14 19:23:45 PDT ---
Ah. I should have read more carefully. I thought that you said "Careful Jonathan, you're talking as if D2 is _at_ the end of the development roadmap for D as a language," meaning that D2 is near the end of its development - which in theory, it is. I misunderstood. You meant that D2 is not the end, and I was talking like it was.

No, D2 is not the end of D's development. Presumably, we'll have a D3 eventually, so maybe such enhancement requests are worth keeping around for that, but we probably should go through and clean many of them up. And if we truly think that a particular enhancement request is never going to happen, then it should be removed. This one _might_ happen in D3, so that would be an argument for keeping it around. I'd definitely like to see the cruft removed from bugzilla though so that there isn't as much that we have to sift through. And I think that the fact that enhancement requests generally do need someone championing them still holds, so just having it in bugzilla isn't going to lead to it being implemented for D3, even if it _is_ a good idea.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3889


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com


--- Comment #14 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2012-02-27 13:40:38 PST ---
There's also:
arr = null;

Would you have to change that to `arr = []` to fit the enhancement request? That would break so much code.

I see no benefit to banning the usage of null.

And to get a little personal, if you care about code readability so much, bear, how about stopping using single-letter variable names or complex single-line expressions in your own code?

These are some excerpts from your code:
c[r1] = [9 * i + j, (i/3*3 + j/3) * 9 + k + 81, 9 * i + k + 162, 9 * j + k +
243];
if (sr[rr = aux.r[c][r2]]++ != 0)
if (--sr[rr = aux.r[c][r2]] != 0)

Next time you talk about clarity take a look at your own code first.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3889



--- Comment #15 from bearophile_hugs@eml.cc 2012-02-27 15:13:27 PST ---
(In reply to comment #14)
> There's also:
> arr = null;
> 
> Would you have to change that to `arr = []` to fit the enhancement request? That would break so much code.
> 
> I see no benefit to banning the usage of null.

In well designed language it's good for different literals to represent different things. Ideally a 1:1 relation. This avoids troubles, and makes code reading and writing less bug prone and clear. In practice such 1:1 relation is not always possible or desirable, but it's a line guide still.

In D there is already a literal that represents "empty array". Using two different literals to represent the same thing is not so do. And especially so if one of them looks much fitter to represent something else.

[] is a very good literal to represent an empty array (elsewhere I have suggested to use [:] as literal to represent empty associative array, but this is not present in D), it's clear and natural for this purpose.

In D "null" is a good literal to represent a pointer pointing to the default, zero address, etc.

Since some time ago in D the concept of array was conflated with the concept of pointer (well, fat pointer). Some of my bug reports on this have being accepted and implemented, and lately arrays are behaving less and less as pointers. Refusing "null" as literal for an empty array is another step in such good direction.

In D there is some confusion between empty array and null array. It's a problem
that comes out all the time for D newbies, this is the last thread:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=33046

It's not just a problem for newbies, here there is a source of bugs for people that know some more D too.

I am aware this is a small breaking change. And Walter and Andrei have the right to close down this enhancement request if they want so. But there are solid reasons behind this enhancement request.


> Next time you talk about clarity take a look at your own code first.

I don't write code like that in production code.

Code is written or copied for various levels of intended usage. There are 5-minutes snippets, code for quick benchmarks or tests to show to other people, code written for online "code golf" contests, routines for small games written in a weekend, code that must be used in critical situations, library code that must be as much bug-free as possible, etc. They naturally have different level of bug-count, clarity, compactness, documentation, amount of contracts and preconditions and unit-tests, amount of brain work done on them, etc. It's wrong to think all of them must have the same characteristics and qualities.

But the most important things you are missing are:
- This enhancement request is about _language design_.
- Bugzilla is not the place for discussions about persons.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------