On Tue, Dec 11, 2018 at 03:34:28PM +0000, Simen Kjærås via Digitalmars-d-announce wrote: [...]
> I believe a reasonable case can be made for .! for UFCS - it's currently invalid syntax and will not compile, and ! is the symbol we already associate with template instantiation:
> 
> alias memberFunctions = __traits(allMembers, T)
>     .!staticMap!Member
>     .!Filter!(isSomeFunction);
[...]

+1.


T

-- 
Too many people have open minds but closed eyes.

On Tuesday, 11 December 2018 at 15:34:28 UTC, Simen Kjærås wrote:
>
> I believe a reasonable case can be made for .! for UFCS - it's currently invalid syntax and will not compile, and ! is the symbol we already associate with template instantiation:
>
> alias memberFunctions = __traits(allMembers, T)
>     .!staticMap!Member
>     .!Filter!(isSomeFunction);
>
> --
>   Simen

Perhaps. I also think that it might be good if types could be results of compile-ime expressions, including ufcs expressions (so that 42.typeof would become legal, meaning an int).

On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
> A few things that have annoyed me about writing D lately:
>
> https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/

Template lambdas and better eponymous template syntax are the two big ones that I would really like. It's very painful not having them in code that makes heavy use of metaprogramming.

On Tuesday, 11 December 2018 at 20:44:28 UTC, Dukc wrote:
> On Tuesday, 11 December 2018 at 15:34:28 UTC, Simen Kjærås wrote:
>>
>> I believe a reasonable case can be made for .! for UFCS - it's currently invalid syntax and will not compile, and ! is the symbol we already associate with template instantiation:
>>
>> alias memberFunctions = __traits(allMembers, T)
>>     .!staticMap!Member
>>     .!Filter!(isSomeFunction);
>>
>> --
>>   Simen
>
> Perhaps. I also think that it might be good if types could be results of compile-ime expressions, including ufcs expressions (so that 42.typeof would become legal, meaning an int).

I vaguely remember a very ancient version of D that had <expression>.typeof instead of typeof(<expression>). This might've been D1... the details are fuzzy.

On Tuesday, 11 December 2018 at 14:38:25 UTC, Steven Schveighoffer wrote:

> @property: This was almost about to be awesome, but squabbling amongst the D core team killed it.

Yes, the problem with @property is that it is neither correctly implemented nor completely implemented.  And to do the former something will have to break.

Note that you can't use binary assignment operators on parentheses-less function calls, and returning by ref is not a solution either. Not only does that break encapsulation, but some @property functions may not return an addressable lvalue (e.g. when working with bitfields).

One might be able to fix the @property implementation, but now, there's so much disdain for the incorrect, incomplete @property implementation it's going to take some serious sweetener to remove the bitter taste from some people's mouths.

Mike

On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
> A few things that have annoyed me about writing D lately:
>
> https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/


> No UFCS chain for templates.
> No template lambdas.

You can write code like this today via library that I wrote ;)

```
import std.conv : to;

auto filterMembers(alias pred, type)(type _)
{
    import std.format : format;
    alias MemberType(T, string name) = typeof(__traits(getMember, T, name));
    return l!(__traits(allMembers, type.get))
        .staticMap!(name => π!(MemberType!(type.get, name.get), name.get))
        .staticFilter!pred
        .staticMap!(t => "%s %s".format(t.get[0].stringof, t.get[1]));
}

enum members = [ π!S.filterMembers!(t => is(t.get[0] : U[], U)).get ];

pragma (msg, members.to!string); // Prints: ["string wxyz", "int[4] uvwxyz"]

struct S
{
    int x;
    double xy;
    int xyz;
    string wxyz;
    S* vwxyz;
    int[4] uvwxyz;
}
```

Here's a full example: [2]

Though, I agree that this certainly not as elegant and straightforward to use as what a language feature could provide.

[1]: https://github.com/dlang/phobos/pull/5977/files#diff-33b50b4967214bfd07ca2ebb7bbc023cR1218

[2]: https://run.dlang.io/gist/ZombineDev/a808c94857de84858accfb094c19bf77?compiler=dmd&args=-unittest%20-main

On 12/11/2018 4:51 AM, Nicholas Wilson wrote:
> > Returning a reference
> Wow, thats f*ck'n stupid! https://run.dlang.io/is/SAplYw

It's quite deliberate.

ref in C++ is a type constructor, but it's so special-cased to behave like a storage class, it might as well be one. In D it is.

(For example, ref in C++ can only appear at the top level. There are no "pointers to refs".)

refs exist so the lifetime of them can be controlled for memory safety. Treating them as flexibly as pointers would make that pretty difficult. refs are the primary way a memory safe container can expose pointers to its contents.

On Tuesday, 11 December 2018 at 12:57:03 UTC, Atila Neves wrote:
> @property is useful for setters. Now, IMHO setters are a code stink anyway but sometimes they're the way to go. I have no idea what it's supposed to do for getters (nor am I interested in learning or retaining that information) and never slap the attribute on.

Imagine you have void delegate() prop() and use the property without parentheses everywhere then suddenly m.prop() doesn't call the delegate. So it's mostly for getters and should be used only in edge cases, most code should be fine with optional parens.

>inout
>Template this can accomplish the same thing and is more useful anyway.

"Everything is a template" is a spiritual successor to "everything is an object" hype :)

>Returning a reference
>It’s practically pointless.

See https://github.com/dlang/druntime/blob/master/src/core/stdc/errno.d#L66
Also AFAIK alias this doesn't dereference pointers automatically, and retaining the pointer may be not desirable.

>I think there’s a general consensus that @safe, pure and immutable should be default.

I can agree there are at least 5 people holding that firm belief, but that's hardly a consensus.

>I’ve lost count now of how many times I’ve had to write @safe @nogc pure nothrow const scope return. Really.

If immutable was default, wouldn't you still need to write const attribute everywhere, and @nogc, and nothrow? Strings are like the only relevant immutable data structure (and they are already immutable), everything else is inherently mutable except for use cases with genuine need for immutability like a shared cache of objects.

On Tuesday, 11 December 2018 at 14:00:10 UTC, dayllenger wrote:
> On Tuesday, 11 December 2018 at 13:42:03 UTC, Guillaume Piolat wrote:
>> One could say getters and particularly setters don't really deserve a nicer way to write them. It's a code stink, it deserve a long ugly name.  (10 years ago I would be in the other camp)
>
> Can you please explain it in more detail? I never read such about getters and setters.

Tell, don't ask: https://martinfowler.com/bliki/TellDontAsk.html

Getters and setters break encapsulation - the client knows way too much about your struct/class. Whatever you were going to do with the data you got from the object, move it into a member function of that object's type.

Setters are like that as well, but worse since mutable state is the root of all evil. Personally, I cringe whenever I have to use `auto` instead of `const` for a variable declaration.

On Wednesday, 12 December 2018 at 14:48:23 UTC, Atila Neves wrote:
> On Tuesday, 11 December 2018 at 14:00:10 UTC, dayllenger wrote:
>> On Tuesday, 11 December 2018 at 13:42:03 UTC, Guillaume Piolat wrote:
>>> One could say getters and particularly setters don't really deserve a nicer way to write them. It's a code stink, it deserve a long ugly name.  (10 years ago I would be in the other camp)
>>
>> Can you please explain it in more detail? I never read such about getters and setters.
>
> Tell, don't ask: https://martinfowler.com/bliki/TellDontAsk.html

Sometimes formulated slightly differently as "Law of Demeter" https://en.wikipedia.org/wiki/Law_of_Demeter

if you like more pompous names.