August 16, 2017
On Tuesday, 15 August 2017 at 21:05:09 UTC, bachmeier wrote:
> On Tuesday, 15 August 2017 at 20:31:50 UTC, Jonathan Marler wrote:
>
>> Without alot of usage, it will just be an esoteric construct that looks confusing to the average developer.
>
> That is correct. After a while it gets tiring to see a neverending stream of complexity added to the language while things that would actually help (like IDE support) do not get any attention. As a general rule, if it's being added to C++, it's probably a bad idea.

There are two thinks of c++ that I miss a little on D:
- Structured binding
- Uniform initialization

But in general, I agreed with you.
August 16, 2017
On Wednesday, 16 August 2017 at 13:40:47 UTC, Guillaume Boucher wrote:
> On Wednesday, 16 August 2017 at 12:58:03 UTC, Joakim wrote:
>>> That is correct. After a while it gets tiring to see a neverending stream of complexity added to the language while things that would actually help (like IDE support) do not get any attention.
>>
>> +1, though I'd go for bug-fixing over IDEs.
>
> I like that.  Feature freeze D until *all* bug reports are closed.
> While that would mean no more features for several years, I think it would benefit the language in the long run, both internally (less discussions about incorrect behavior) and externally (D is a mature and stable language).

You'd see a fork.
August 17, 2017
On Wednesday, 16 August 2017 at 14:19:59 UTC, SrMordred wrote:
> On Tuesday, 15 August 2017 at 21:05:09 UTC, bachmeier wrote:
>> On Tuesday, 15 August 2017 at 20:31:50 UTC, Jonathan Marler wrote:
>>
>>> Without alot of usage, it will just be an esoteric construct that looks confusing to the average developer.
>>
>> That is correct. After a while it gets tiring to see a neverending stream of complexity added to the language while things that would actually help (like IDE support) do not get any attention. As a general rule, if it's being added to C++, it's probably a bad idea.
>
> There are two thinks of c++ that I miss a little on D:
> - Structured binding
> - Uniform initialization
>
> But in general, I agreed with you.

Initialization in D is pretty uniform now though. What corners am I missing?

It's usually:

    <type-or-infer> name = <constructor>(args);

Structured bindings... I think C++ did it badly, actually. They had the {...} syntax fr object construction that worked everywhere and using the same for deconstruction would've allowed for quite natural tuples, which manifest almost as language-level constructs by then (with the help of 'auto' in template parameters).
August 18, 2017
On Thursday, 17 August 2017 at 13:11:51 UTC, Enamex wrote:
> On Wednesday, 16 August 2017 at 14:19:59 UTC, SrMordred wrote:
>> On Tuesday, 15 August 2017 at 21:05:09 UTC, bachmeier wrote:
>>> [...]
>>
>> There are two thinks of c++ that I miss a little on D:
>> - Structured binding
>> - Uniform initialization
>>
>> But in general, I agreed with you.
>
> Initialization in D is pretty uniform now though. What corners am I missing?
>
> It's usually:
>
>     <type-or-infer> name = <constructor>(args);
>
> Structured bindings... I think C++ did it badly, actually. They had the {...} syntax fr object construction that worked everywhere and using the same for deconstruction would've allowed for quite natural tuples, which manifest almost as language-level constructs by then (with the help of 'auto' in template parameters).

Nothing too serious, just miss somethings like:
void add_vec( vec2 a, vec2 b );
add_vec( {10,20}, {20,30} );

1 2
Next ›   Last »