On Sunday, 22 September 2013 at 03:37:02 UTC, Zhouxuan wrote:
> From what I see, as a new user of D, D's current feature set is so exciting and rich enough that I'm willing to give it a try. However, I feel frustrated because some simple usage about some feature I excerice failed, take AA for example, it's a basic feature as described in TDPL, but I even can't use it to store an array indexed by a string (http://d.puremagic.com/issues/show_bug.cgi?id=10970),no matter whatever you explaned, it's the truth that I feel AA is not usable and I give up AA (or maybe whole D given that AA is advertised to be a very basic feature).It's really a big problem and you guys should focus more on it if D wanna gain more popularity IMHO.

Yes, AA is definitively the fastest road toward problems.

> On the other hand, D's feature is attractive, no matter how much buggy is it, the expectation that it'll be solved once D gain more popularity and more and more programmers are innvolved in D may keep me learn and practise D as a hobby, but where's the expectation comes from? IMHO, D need a more organized team, meet once a week or two on irc, report your effort and finally post it to public (maybe filtered) like Rust meeting on its wiki page. So that every new user is convinced that D's in a virtuous circle and every issue they care about is being worked on, as well as a future plan (if not being worked ATM) on those issues most mentioned in NG/IRC etc like GC.

Most issue are being worked on. That being said, changing semantic in a programming language is always a difficult matter, as people code relying on the old bugguy behavior may break.

On 9/21/2013 8:17 PM, Michel Fortin wrote:
> You could *replace* the line number with a "byte from start of file" and then
> compute lazily either the line number or the column number for the rare times
> where you actually need to get the line or column number. (Ideally you'd also
> keep a map of the byte offset for the start of each line in a file to make that
> computation fast.)

That's an expensive computation. The trouble is, "compile with symbolic debug info on" is when you want fast compiles, and you'll need the line number everywhere.

> Column values are of interest in an IDE because it can pinpoint the error more
> precisely. The IDE can show exactly where the error is (for instance with a
> dotted red underline),

I do understand this.

On 9/21/2013 8:54 PM, Michel Fortin wrote:
> I don't think it should be a priority, but rejecting the idea outright is
> shortsighted in my opinion.

I'm not rejecting the idea outright. I've actually implemented this in the dmc compiler. It's just not terribly useful, and it has costs.

On 9/21/2013 9:34 PM, deadalnix wrote:
> Most issue are being worked on. That being said, changing semantic in a
> programming language is always a difficult matter, as people code relying on the
> old bugguy behavior may break.

And often the same people who want semantic changes are the ones who complain when new features break things :-(

On Saturday, 21 September 2013 at 22:36:44 UTC, Walter Bright wrote:
>
> Ok, so it found a latent bug in the source code - I don't think that's a good example of dmd being unstable - it was a good change.

OK, this was a latent bug in sources. I think this is not the first and not the last event when dmd starts rejecting buggy code. However that means that before the change dmd accepted invalid and this jeopardizes D implementation. And anyway, irrespectively of whether issue is a true regression or fixing accepts-invalid bug, for majority of users this doesn't play much role but means creating problems of code breakage in each release.

On Saturday, September 21, 2013 23:54:26 Michel Fortin wrote:
> On 2013-09-22 03:32:26 +0000, Jonathan M Davis <jmdavisProg@gmx.com> said:
> > On Saturday, September 21, 2013 23:17:23 Michel Fortin wrote:
> >> Column values are of interest in an IDE because it can pinpoint the error more precisely. The IDE can show exactly where the error is (for instance with a dotted red underline), often allowing you to fix the error without even reading the error message (especially when it's a typo). With a background-compilation-as-you-type system you know almost immediately when you make an error, and you know where it is.
> > 
> > A lexer being used by an IDE definitely needs the column number, but the normal compiler doesn't.
> 
> I was referring to how the IDE can show the compiler's error messages better when the column number is available, not to how it does syntax highlighting. Xcode uses this a lot, and clang's error log provides full character ranges for errors, not just a column number, making the visualization of errors much better and pleasant to work with.
> 
> But indeed, no one *needs* that. Like everything else, it's just a convenience.
> 
> I don't think it should be a priority, but rejecting the idea outright is shortsighted in my opinion.

I don't think that it's at all worth it for compiling with the compiler on the command line. The situation changes somewhat when an IDE gets involved.

- Jonathan M Davis

2013/9/22 Zhouxuan <pycerl@qq.com>

> http://d.puremagic.com/**issues/show_bug.cgi?id=10970<http://d.puremagic.com/issues/show_bug.cgi?id=10970>


That is a long-standing bug around AA value setting and opAssign, and
fortunately I recently tried to fix it by determining the language
semantics.
https://github.com/D-Programming-Language/dmd/pull/2539

Kenji Hara

On Sunday, 22 September 2013 at 05:23:50 UTC, Walter Bright wrote:
> On 9/21/2013 9:34 PM, deadalnix wrote:
>> Most issue are being worked on. That being said, changing semantic in a
>> programming language is always a difficult matter, as people code relying on the
>> old bugguy behavior may break.
>
> And often the same people who want semantic changes are the ones who complain when new features break things :-(

Guilty here :D

On Sunday, 22 September 2013 at 00:33:32 UTC, Walter Bright wrote:
> On 9/21/2013 5:11 PM, Sean Kelly wrote:
> someone's entire source file is on one line, and on it goes.

OTOH, this is exactly the showcase where such a feature would be *really* useful.

On Saturday, 21 September 2013 at 22:08:23 UTC, Andrej Mitrovic wrote:
> On 9/21/13, Maxim Fomin <maxim@maxim-fomin.ru> wrote:
>> (like AAs, scope, shared) are at risk to be seriously changed which is a
>> serious problem to the user.
>
> These are already a serious problem to the user when they're broken
> and under-implemented.

I'm really hoping for an improvement of shared and the concurrency field.
It's a pity having someone that having read the concurrency chapter of TDPL (for free, also!) start toying with shared and... "hey, it does not works that way? where's the "actual" documentation then? what is the timeline? what? no timeline? gheeez" (really happened, BTY)

/Paolo