On Tuesday, 22 November 2016 at 19:16:56 UTC, Ali Çehreli wrote:
> On 11/22/2016 08:05 AM, Satoshi wrote:

> I don't have extensive experience with other languages. In fact, the only other languages that I can claim proficiency are C and C++. (I also know Python just enough to find it incredible how it's used in the industry. Let's not get in to that discussion but I really tried and failed... in industry... :) ) Given that experience, I still find D a very useful tool.
>

D is one o the best languages what exists, it's reason why I'm using it. But some issues are solved better in other languages like rust, go or swift.


> Agreed but it opens the door for bugs. Assuming
>
> struct A { int a; }
> struct B { int b; int c; }
>
> void foo(int, int, int);
>
> If foo(1, 2, 3) meant foo(A(1), B(2, 3)) today, it could silently mean foo(A(1, 2), B(3)) if one moved one member from one struct to the other.
>
> Then there are other corner cases:
>
>     writeln(1, 2, 3);
>
> Should that print the integers or A(1) and B(2, 3)? It's always better to be explicit.
>

argument expand should be applied only to the last argument and cannot be used in variadic templates. Like in my simple example where I exactly know what function will do, but I want to call it by simplest way.

It actually works with classes, but no with structs.


> import std.stdio;
>
> struct Point {
>     int x;
>     int y;
> }
>
> struct GraphicsContext {
>     static GraphicsContext current() {
>         return GraphicsContext();
>     }
>
>     void moveTo(Point point) {
>         writefln("Moving to %s", point);
>     }
>
>     void lineTo(Point point) {
>         writefln("Drawing line to %s", point);
>     }
> }
>
> void goTo(GraphicsContext gc, int x, int y) {
>     gc.moveTo(Point(x, y));
> }
>
> void drawTo(GraphicsContext gc, int x, int y) {
>     gc.lineTo(Point(x, y));
> }
>
> void main() {
>     auto gc = GraphicsContext.current;
>     gc.goTo(70, 70);    // <-- Clean syntax
>     gc.drawTo(70, 170);
> }

But I need to write overload function for every function taking simple messengers like Point/Size/Rectangle

or I have simple class

class View {
this(Rectangle frame) {...}
this(float, float, float, float) { ... }
this(Point, Size) { ... }
}

then struct Point, Size and Rectangle (Point, Size)

now I need to write 2 overloads for View class taking 4 floats or (Point, Size) and this must do in every descendant of View class.

On Tuesday, 22 November 2016 at 16:57:28 UTC, kink wrote:
>
> I hate this 'idiom' too (just a clumsy workaround for something that should work out of the box), but the non-bindability of rvalues to ref params and the associated dispute is veeery old, nothing new, so I don't agree that the language gets worse every day. ;)

d-idioms doesn't always paint a rosy picture of D, that's true. It's about "what can we do now with D, whatever it takes". It turns out almost everything can be done, but some things are worse than in other languages of course.

The baby is too cute to throw with the bathwater ;)

On Tuesday, 22 November 2016 at 16:05:35 UTC, Satoshi wrote:
> Sorry, but D seems to be worse and worse day by day. This should be resolved by language and not doing it by template function.
> Same thing should be applied for maybe monad and tuples.

 I'm reminded of trying to follow the rules and do both L&R types, and I came across unwanted behavior since the qualifiers would make something the wrong type because constness was closer matching, among other weird behavior.

 I'll hope more of this gets resolved, and then I can look at the language seriously and really do something with it.

On Tuesday, 22 November 2016 at 22:03:14 UTC, Satoshi wrote:
> or I have simple class
>
> class View {
> this(Rectangle frame) {...}
> this(float, float, float, float) { ... }
> this(Point, Size) { ... }
> }
>
> then struct Point, Size and Rectangle (Point, Size)
>
> now I need to write 2 overloads for View class taking 4 floats or (Point, Size) and this must do in every descendant of View class.

This can be solved with string-mixins.

On Tuesday, 22 November 2016 at 13:06:27 UTC, Nordlöw wrote:
> On Monday, 21 November 2016 at 20:04:51 UTC, Ali Çehreli wrote:
>> mixin template RvalueRef()    // <-- DOES NOT TAKE A PARAMETER ANY MORE
>> {
>>     alias T = typeof(this);
>>     static assert (is(T == struct));
>>
>>     @nogc @safe
>>     ref const(T) byRef() const pure nothrow return
>
> Why do you need to qualify `byRef` as pure nothrow when it's a template?

The thing that gets me more is "return" as a function attribute. I see it under "MemberFunctionAttribute" in the grammar but I can't find an explanation for its use anywhere...

On Thursday, 24 November 2016 at 00:35:39 UTC, TheGag96 wrote:
> The thing that gets me more is "return" as a function attribute. I see it under "MemberFunctionAttribute" in the grammar but I can't find an explanation for its use anywhere...

YOU ARE NOT SUPPOSED TO KNOW THIS. DON'T LIVE YOUR PLACE, WE SENT A VAN FOR YOU.

On Thursday, November 24, 2016 00:35:39 TheGag96 via Digitalmars-d-learn wrote:
> On Tuesday, 22 November 2016 at 13:06:27 UTC, Nordlöw wrote:
> > On Monday, 21 November 2016 at 20:04:51 UTC, Ali Çehreli wrote:
> >> mixin template RvalueRef()    // <-- DOES NOT TAKE A PARAMETER
> >> ANY MORE
> >> {
> >>
> >>     alias T = typeof(this);
> >>     static assert (is(T == struct));
> >>
> >>     @nogc @safe
> >>     ref const(T) byRef() const pure nothrow return
> >
> > Why do you need to qualify `byRef` as pure nothrow when it's a template?
>
> The thing that gets me more is "return" as a function attribute. I see it under "MemberFunctionAttribute" in the grammar but I can't find an explanation for its use anywhere...

I believe that that has to do with DIP 25, which is enabled with the -dip25 compiler switch:

http://wiki.dlang.org/DIP25

- Jonathan M Davis

On Thursday, 24 November 2016 at 00:35:39 UTC, TheGag96 wrote:
> The thing that gets me more is "return" as a function attribute. I see it under "MemberFunctionAttribute" in the grammar but I can't find an explanation for its use anywhere...

I've started documenting it now, will post a PR soon.

On Friday, 25 November 2016 at 17:21:52 UTC, Nick Treleaven wrote:
> I've started documenting it now, will post a PR soon.

https://github.com/dlang/dlang.org/pull/1519