On Tuesday, 24 October 2017 at 04:26:42 UTC, Adam Wilson wrote:
> (at the end of the day all of these programming models are callback based).

That's what APM is, no?

> Yes, C#'s async design does make code look and feel synchronous, and it was intentionally designed that way, but that is not *why* they did Async.

You can do APM in .net 4.0 with tasks and callbacks (we do it at work), the only purpose of async/await is to make it look nice and synchronous.

On Tuesday, 24 October 2017 at 05:40:06 UTC, Dmitry Olshansky wrote:
> On Tuesday, 24 October 2017 at 04:26:42 UTC, Adam Wilson wrote:
>>[...]
>
> I’ll throw in my 2 rubbles.
>
> I actually worked on a VM that has async/await feature built-in (Dart language).
> It is a plain syntax sugar for Future/Promise explicit asynchrony where async automatically return Future[T] or Observable[T] (the latter is async stream).
>
> [...]

This is exactly what async/await in C# does.
I saw this idea in Jeffry Richter's Power Threading library (https://github.com/Wintellect/PowerThreading) sometime in the mid/late 2000, where he used the C# 'yield' keyword to generate the state machine code. When async/await was added MSFT either took his idea directly or at the very least got inspired by it.

On Tuesday, 24 October 2017 at 16:02:56 UTC, flamencofantasy wrote:
> On Tuesday, 24 October 2017 at 05:40:06 UTC, Dmitry Olshansky wrote:
>> On Tuesday, 24 October 2017 at 04:26:42 UTC, Adam Wilson wrote:
>>>[...]
>>
>> I’ll throw in my 2 rubbles.
>>
>> I actually worked on a VM that has async/await feature built-in (Dart language).
>> It is a plain syntax sugar for Future/Promise explicit asynchrony where async automatically return Future[T] or Observable[T] (the latter is async stream).
>>
>> [...]
>
> This is exactly what async/await in C# does.
> I saw this idea in Jeffry Richter's Power Threading library (https://github.com/Wintellect/PowerThreading) sometime in the mid/late 2000, where he used the C# 'yield' keyword to generate the state machine code. When async/await was added MSFT either took his idea directly or at the very least got inspired by it.

Async/await was based on Midori's project related work.

http://joeduffyblog.com/2015/11/19/asynchronous-everything/

--
Paulo

On Tuesday, 24 October 2017 at 09:56:50 UTC, rikki cattermole wrote:
> scope+ref+out as arguments would be a no-no.
> Now if we could ditch registers usage crossing before/after yield, we wouldn't need to do 'patching' like fibers do.

That's basically what asnyc/await does, some implementations as continuation (callback) some as jump rewrite.

On Monday, 23 October 2017 at 13:18:21 UTC, Guillaume Piolat wrote:
>> By any means, if someone wants to help here, get in touch with Benjamin Thaut and me.
>> This has been lingering around for way to long, and Benjamin alone has a hard time pushing this.
>
> Would Bountysource help be adequate?

Not sure about Benjamin, but on my side it's time limited.
I'd Bountysource didn't work out too well for us.

On Monday, 23 October 2017 at 11:58:14 UTC, Laeeth Isharc wrote:
> Bountysource went quiet, though I started contributing to it.
> I wonder if there is a better way for commercial users to say what they might be willing to pay for and how much.

At best talk to Andrei, maybe you have a good idea to do this over the Foundation.

On Tuesday, October 24, 2017 18:53:49 Martin Nowak via Digitalmars-d wrote:
> On Monday, 23 October 2017 at 13:18:21 UTC, Guillaume Piolat
>
> wrote:
> >> By any means, if someone wants to help here, get in touch with
> >> Benjamin Thaut and me.
> >> This has been lingering around for way to long, and Benjamin
> >> alone has a hard time pushing this.
> >
> > Would Bountysource help be adequate?
>
> Not sure about Benjamin, but on my side it's time limited. I'd Bountysource didn't work out too well for us.

For it to work, it would likely either have to encourage developers who aren't involved to get involved or provide enough money that developers who are already involved could spend more time on D (e.g. because they're a contractor and the money from a bounty was able to temporarily function as their source of income). I don't think that either happened. Most of the bounties were pretty small, and most full-time employees who work with D in their free time are unlikely to be able to spend more time on D due to some extra money, because time is the concern, not money. Best case, I'd expect bountysource to encourage folks already working on D to work on something specific, because they'd get a bit of extra money for it, but that doesn't seem to have happened. I think that most of the folks contributing have forgotten about bountysource entirely.

Anyone looking to help D grow via money is probably better off donating to the D foundation - though whether this particular item is high enough of the priority list for the D foundation to pay someone to work on it, I don't know, and I don't know if there's someone with the appropriate skillset who's available to be paid to work on it. The D Foundation is pretty new at this (but the fact that it exists at all is a huge step forward).

There has been some interest in "improved DLL" support, which ties into improving export on Windows, but there doesn't seem to have been a lot of interest in actually working on it (at least not from folks with the time to).

- Jonathan M Davis

On Monday, October 23, 2017 13:18:21 Guillaume Piolat via Digitalmars-d wrote:
> On Monday, 23 October 2017 at 11:39:58 UTC, Martin Nowak wrote:
> >> Every-symbol-public-by-default in Posix is annoying though :)
> >
> > We agreed on hidden visibility by default for everything that's
> > not exported.
> > This requires export to be fixed on non-Windows machines first.
>
> This is especially interesting since hidden visibility for most symbols is required to make -dead_strip effective (strips most of the object code here).

There are good technical reasons for requiring export, but man do I hate having to deal with it when doing Windows development in C++. It is _so_ nice to not have to care when working on *nix codebases in C++ and so annoying to deal with it when I have to worry about Windows that I lean heavily towards not wanting export to be required in D even if there are some definite technical problems with it. I've never had good things to say about having to export stuff on Windows, no matter the language.

- Jonathan M Davis

On 10/24/2017 3:36 AM, Satoshi wrote:
> Can you provide an example?

I'd start with https://dlang.org/spec/interface.html

You'll see the same thing with Windows COM programming, and using interfaces in Java.

---- view.di ----
interface View {
    void render();
}
View createView();

---- button.di ----
import view;
interface Button : View {
    void simulateClick();
}
Button createButton();

---- closed_src_library.d ----
import view, button;
private class LibraryView : View {
   int hidden_data;
   void render() { do something with hidden_data }
}

private class LibraryButton : Button {
    int hidden_data;
    void simulateClick() { .... }
}

View createView() {
    return new LibraryView();
}

View createButton() {
    return new LibraryButton();
}

--- my_extension.d ---
import view, button;
class ExtendView : View {
    View base;
    this() {
        base = createView();
    }
    void render() {
        base.render();
        ... do my rendering ...
    }
}

On 23.10.2017 22:47, Walter Bright wrote:
> On 10/18/2017 1:56 AM, Satoshi wrote:
>> Unable to publish closed source library without workaround and ugly PIMPL design.
> 
> 
> Consider this:
> 
> ----------- file s.d ------------
>    struct S {
>      int x;
>      this(int x) { this.x = x; }
>      int getX() { return x; }
>    }
> ----------- file s.di ------------
>    struct S {
>      this(int x);
>      int getX();
>    }
> --------------------------
> 
> User code:
> 
>      import s;
>      S s = S(3);
>      writeln(s.getX());

I doubt this reserves enough space on the stack for the copy.

> 
> Ta dah! Implementation is hidden, no PIMPL. Of course, inlining of the member functions won't work, but it won't work in C++, either, when this technique is used.
> 
> I.e. you can use .di/.d files just like you'd use .h/.cpp in C++. The technique works with classes, too.