On Wednesday, 7 August 2013 at 17:01:36 UTC, Borislav Kosharov wrote:
> Yea, I don't like how you have to write properties in D. I usually write them like this:
> @property {
>     int myNum() {
>         return _myNum;
>     }
>     void myNum(int value) {
>         _myNum = value;
>     }
> }
>
> I saw that in the D conf it was stated that @property will be changed? I was wondering if there is any progress on that and how will the new properties look like? Are they going to be replaced by templates or something else? Has anyone written his own property generators?

There is a pending pull request from Kenji: https://github.com/D-Programming-Language/dmd/pull/2305 , but does not do anything crazy, just enforces existing approach and addresses some of nasty corner cases.

I doubt it will ever change to something like in C# - as time passes, people are more and more reluctant to make any breaking change unless it fixes some really major problem.

I personally just avoid using them at all.

On Wednesday, 7 August 2013 at 14:12:32 UTC, eles wrote:
> What I perceived: language should state on those several ambiguous issues (@property was quoted, complex numbers) and tools should get some maturity (the .so thing for one).

I think it is a very important moment that is often underestimated. Sometimes lack of clear plans for future is even more harmful than existing buggy implementation. For some features most stressing fact is not they do not work or will work in unwelcome way - it is the fact that no authority provides clear opinion on how they should work.

On Wednesday, 7 August 2013 at 17:09:16 UTC, Dicebot wrote:
> On Wednesday, 7 August 2013 at 17:01:36 UTC, Borislav Kosharov I personally just avoid using them at all.

That's the danger that roots in the lack of clarity. And, I cannot blame people outside thinking along the same lines about the entire D: "I personally just avoid using it at all".

Sad, but true.

On Wednesday, 7 August 2013 at 14:12:32 UTC, eles wrote:
> On Wednesday, 7 August 2013 at 02:27:42 UTC, Walter Bright wrote:
>> On 8/6/2013 4:28 PM, MattCoder wrote:
> What I perceived: language should state on those several ambiguous issues (@property was quoted, complex numbers) and tools should get some maturity (the .so thing for one).

For example: the .so thing was critical for what we had in mind at that time: write MEX files for Matlab. Those MEX files are nothing else than some dynamic libraries that expose a particular function mexFunction() that is recognized by Matlab. They can speed up scientific computation in Matlab, by coding number crunching in that dynamic library.

More: the DLL itself is opaque. No customer cared in what language we did implement the DLLs.

But we were not able to pick D for that task. You know why.

On Tuesday, August 06, 2013 05:44:25 Jeremy DeHaan wrote:
> I promise I will write some stuff and post in the announce section once I have a little more time.(classes are currently destroying me)

Then switch to structs. ;)

- Jonathan M Davis