On Thursday, 11 February 2016 at 04:51:39 UTC, Matt Elkins wrote:
>> - Syntactic sugars (associtive arrays, powerful foreach, slices...)
>
> I'm still adjusting to the idea of AAs as part of the language rather than library. Not sure I like it, but on the other hand it doesn't really hurt. The foreach construct isn't any better (or worse) than C++'s, unless I'm missing something (which is very possible). But slices are awesome!

In D you can `foreach` over a list of types (AliasSeq) at compile time, not just over ranges at runtime. (For the moment, it's still only available in function bodies though, unlike `static if`.)

On Thursday, 11 February 2016 at 05:05:22 UTC, tsbockman wrote:
> On Thursday, 11 February 2016 at 04:51:39 UTC, Matt Elkins wrote:
>>> - Syntactic sugars (associtive arrays, powerful foreach, slices...)
>>
>> I'm still adjusting to the idea of AAs as part of the language rather than library. Not sure I like it, but on the other hand it doesn't really hurt. The foreach construct isn't any better (or worse) than C++'s, unless I'm missing something (which is very possible). But slices are awesome!
>
> In D you can `foreach` over a list of types (AliasSeq) at compile time, not just over ranges at runtime. (For the moment, it's still only available in function bodies though, unlike `static if`.)

Neat! I didn't know that. You can do that in C++, but in typical fashion not with a convenient foreach statement. You have to do some crazy type list recursion stuff.

So chalk up another point for D's "ease of metaprogramming" :).

On 2/10/16 11:51 PM, Matt Elkins wrote:

> * The in keyword. This is nice syntactic sugar over having a special
> trait in C++ which deduces whether to pass by value or const-reference.
> "foo(in bar)" is way more readable than something like
> "foo(traits<bar>::fast_param bar)"

Hm... in is short for scope const. It is not pass by reference. Perhaps you meant auto ref?

> * @property. This little feature has been invaluable in porting my C++
> code, letting me shave off tons of accessors and mutators that existed
> only for the sake of possibly being needed in the future. I didn't even
> need to use @property for this; its simple existence did the work for me!

Well, interestingly, D still allows property syntax without the @property notation. I'm in the habit now of never documenting accessors with @property. Mutators, I still would like to see D require @property to access that syntax.

Note that the only good reason to defensively add accessors and mutators for public fields is to keep a consistent binary API. In other words, if have a shared library. D is not quite there yet for shared library support, however.



-Steve

On Friday, 12 February 2016 at 14:03:05 UTC, Steven Schveighoffer wrote:
> On 2/10/16 11:51 PM, Matt Elkins wrote:
>
>> * The in keyword. This is nice syntactic sugar over having a special
>> trait in C++ which deduces whether to pass by value or const-reference.
>> "foo(in bar)" is way more readable than something like
>> "foo(traits<bar>::fast_param bar)"
>
> Hm... in is short for scope const. It is not pass by reference. Perhaps you meant auto ref?

Right...maybe I've been operating under false pretenses, but I was under the impression that the compiler was allowed to interpret scope const as either "pass by value" or "pass by const reference" freely so long as there was no custom post-blit defined? For the purposes of optimization, I mean, to avoid needless copying.

On 2/12/16 9:37 AM, Matt Elkins wrote:
> On Friday, 12 February 2016 at 14:03:05 UTC, Steven Schveighoffer wrote:
>> On 2/10/16 11:51 PM, Matt Elkins wrote:
>>
>>> * The in keyword. This is nice syntactic sugar over having a special
>>> trait in C++ which deduces whether to pass by value or const-reference.
>>> "foo(in bar)" is way more readable than something like
>>> "foo(traits<bar>::fast_param bar)"
>>
>> Hm... in is short for scope const. It is not pass by reference.
>> Perhaps you meant auto ref?
>
> Right...maybe I've been operating under false pretenses, but I was under
> the impression that the compiler was allowed to interpret scope const as
> either "pass by value" or "pass by const reference" freely so long as
> there was no custom post-blit defined? For the purposes of optimization,
> I mean, to avoid needless copying.

Pass by reference and pass by value means different treatment inside the function itself, so it can't differ from call to call. It could potentially differ based on the type being passed, but I'm unaware of such an optimization, and it definitely isn't triggered specifically by 'in'. 'in' is literally replaced with 'scope const' when it is a storage class.

-Steve

On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer wrote:
> On 2/12/16 9:37 AM, Matt Elkins wrote:
>> [...]
>
> Pass by reference and pass by value means different treatment inside the function itself, so it can't differ from call to call. It could potentially differ based on the type being passed, but I'm unaware of such an optimization, and it definitely isn't triggered specifically by 'in'. 'in' is literally replaced with 'scope const' when it is a storage class.
>
> -Steve

note that 'in' and 'scope'(other than for delegates) parameter storage class usage should be avoided.
It really should be a warning.

On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer wrote:
> It could potentially differ based on the type being passed,

Yes, that's what I meant.

> but I'm unaware of such an optimization,

Hm. Unfortunate.

> and it definitely isn't triggered specifically by 'in'. 'in' is literally replaced with 'scope const' when it is a storage class.

Yeah, I didn't mean 'in' definitely triggered it. I meant that 'in' (or rather, as you say, 'scope const') provides the conditions by which a compiler could make such an optimization, since it can know that the parameter will be unaffected by the function. It seems like that would mean it could, in theory, choose to pass small objects by value and large objects by reference under the hood, to avoid the large object copy (assuming no custom post-blit...and I guess it would have to check for taking the address?). To achieve that in C++ I use a special trait which deduces whether pass-by-value or pass-by-const-reference makes more sense for the type...but maybe I should be doing the same thing in D, if that optimization isn't actually present?

It does seem like the compiler could probably perform that optimization even if 'in' (or 'scope const') wasn't used, if it was smart enough...

This sort of micro-optimization generally doesn't matter at the application level unless one has actually profiled it. But it comes up a lot for me when writing generic libraries which can't know whether it will be used in a situation someday where those optimizations do actually matter.

On Friday, 12 February 2016 at 17:20:23 UTC, rsw0x wrote:
>
> note that 'in' and 'scope'(other than for delegates) parameter storage class usage should be avoided.
> It really should be a warning.

Add to docs!

On Friday, 12 February 2016 at 17:20:23 UTC, rsw0x wrote:
> On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer wrote:
>> On 2/12/16 9:37 AM, Matt Elkins wrote:
>>> [...]
>>
>> Pass by reference and pass by value means different treatment inside the function itself, so it can't differ from call to call. It could potentially differ based on the type being passed, but I'm unaware of such an optimization, and it definitely isn't triggered specifically by 'in'. 'in' is literally replaced with 'scope const' when it is a storage class.
>>
>> -Steve
>
> note that 'in' and 'scope'(other than for delegates) parameter storage class usage should be avoided.
> It really should be a warning.

Why is that?

On Friday, 12 February 2016 at 17:29:54 UTC, Matt Elkins wrote:
> On Friday, 12 February 2016 at 17:20:23 UTC, rsw0x wrote:
>> On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer wrote:
>>> On 2/12/16 9:37 AM, Matt Elkins wrote:
>>>> [...]
>>>
>>> Pass by reference and pass by value means different treatment inside the function itself, so it can't differ from call to call. It could potentially differ based on the type being passed, but I'm unaware of such an optimization, and it definitely isn't triggered specifically by 'in'. 'in' is literally replaced with 'scope const' when it is a storage class.
>>>
>>> -Steve
>>
>> note that 'in' and 'scope'(other than for delegates) parameter storage class usage should be avoided.
>> It really should be a warning.
>
> Why is that?

Unless it has changed, 'scope' is a noop for everything but delegates. Code that works now will break when(if...) it gets implemented.