On 10/24/2017 12:21 AM, Satoshi wrote:
> what about this:
> 
> ---------- file.d
> class Foo {
>    private int bar;
>    private string text;
> 
>    void call() { }
> }
> 
> ----------- file.di
> 
> class Foo {
>    call();
> }
> 
> 
> 
> and then I want to inherit from it (I have access to file.di only)
> class Bar : Foo { // I cannot due I have misleading information about size of Foo
> 
> }


If you don't add data members to Bar, it will work. If you do add data members, then the compiler needs to know the data members in Foo. This is the same in C++ .h files.

You could specify Foo as an interface,

  https://dlang.org/spec/interface.html

and then Bar can inherit from Foo without needing any knowledge of Foo's data members.

On Tuesday, 24 October 2017 at 07:17:08 UTC, Satoshi wrote:
> On Monday, 23 October 2017 at 21:42:03 UTC, Atila Neves wrote:
>> On Monday, 23 October 2017 at 21:14:18 UTC, bauss wrote:
>>> On Monday, 23 October 2017 at 12:48:33 UTC, Atila Neves wrote:
>>>> On Monday, 23 October 2017 at 09:13:45 UTC, Satoshi wrote:
>>>>> On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
>>>>>> [...]
>>>>>
>>>>> Whats about this one?
>>>>>
>>>>> auto foo = 42;
>>>>> auto bar = "bar";
>>>>> writeln(`Foo is {foo} and bar is {bar}`);
>>>>
>>>> writeln("Foo is ", foo, "and bar is ", bar");
>>>>
>>>> Two more characters.
>>>>
>>>> Atila
>>>
>>> Okay, but what about now?
>>>
>>> void sendAMessage(string message)
>>> {
>>>     ....
>>> }
>>
>> sendAMessage(text(...));
>>
>> Atila
>
> boilerplate...

True, but in my opinion not enough to justify complicating the language. One could also always do:

import std.conv: t = text;
sendAMessage(t("Foo is ", foo, " and bar is ", bar"));

If it were me I'd just make `sendAMessage` take a variadic template and call text internally.

Atila

On Tuesday, 24 October 2017 at 07:55:49 UTC, Walter Bright wrote:
> On 10/24/2017 12:21 AM, Satoshi wrote:
>> what about this:
>> 
>> ---------- file.d
>> class Foo {
>>    private int bar;
>>    private string text;
>> 
>>    void call() { }
>> }
>> 
>> ----------- file.di
>> 
>> class Foo {
>>    call();
>> }
>> 
>> 
>> 
>> and then I want to inherit from it (I have access to file.di only)
>> class Bar : Foo { // I cannot due I have misleading information about size of Foo
>> 
>> }
>
>
> If you don't add data members to Bar, it will work. If you do add data members, then the compiler needs to know the data members in Foo. This is the same in C++ .h files.
>
> You could specify Foo as an interface,
>
>   https://dlang.org/spec/interface.html
>
> and then Bar can inherit from Foo without needing any knowledge of Foo's data members.


But it's quite useless to me.


i.e.
class View { }
class Button : View { }

I want to let users to inherit from View or Button and let them customize the elements.
This can be done just by PIMPL.

But doing PIMPL inheritance inside one library is pain in the a$$.

-------------------- view.d ------------------
class View {
  private ViewData _;

  package class ViewData {
    int a, b, c;
  }

  this() {
    initData();
  }

  protected void initData() {
    if (!_) _ = new ViewData;
  }

  void render() { }
}


----------------------- button.d -----------
class Button : View {
  package class ButtonData : ViewData {
    string stuff;
  }

  protected override void initData() {
    if (!_) _ = new ButtonData;
  }

  void simulateClick() { }
}


and headers
------------- view.di ------------
class View {
  private void* _;

  this();
  void render();
}

------------- button.di ---------------
class Button : View {
  void simulateClick();
}



But the worst part is that I need to hold di in sync to d files manually, so there is not any advantages over C++'s header files.

On Tuesday, 24 October 2017 at 08:06:55 UTC, Atila Neves wrote:
> On Tuesday, 24 October 2017 at 07:17:08 UTC, Satoshi wrote:
>> On Monday, 23 October 2017 at 21:42:03 UTC, Atila Neves wrote:
>>> On Monday, 23 October 2017 at 21:14:18 UTC, bauss wrote:
>>>> On Monday, 23 October 2017 at 12:48:33 UTC, Atila Neves wrote:
>>>>> [...]
>>>>
>>>> Okay, but what about now?
>>>>
>>>> void sendAMessage(string message)
>>>> {
>>>>     ....
>>>> }
>>>
>>> sendAMessage(text(...));
>>>
>>> Atila
>>
>> boilerplate...
>
> True, but in my opinion not enough to justify complicating the language. One could also always do:
>
> import std.conv: t = text;
> sendAMessage(t("Foo is ", foo, " and bar is ", bar"));
>
> If it were me I'd just make `sendAMessage` take a variadic template and call text internally.
>
> Atila

so, we should complicate source code instead of the language?

Actually, you provide one of the best examples why we should add this syntactic sugar.

On Monday, 23 October 2017 at 22:22:55 UTC, Adam Wilson wrote:
> Async/Await trades raw performance for an ability to handle a truly massive number of simultaneous tasks.

Vibe achieves the same without trading performance. Then async/await only amounts to easy creation of tasks not even for their main usage scenario at a pretty high price of async/await feature, such tradeoff doesn't sound good to me.

On Tuesday, 24 October 2017 at 07:29:08 UTC, Satoshi wrote:
> If we want to use D for GUI development we will need this feature anyway.

To not block UI you need non-blocking IO, and async/await is not required for it: vibe provides non-blocking IO with synchronous interface. And here we also have another shortcoming of async/await: it doesn't interact well with GUI that traditionally uses synchronous event handlers (mostly because it predates async/await).

On 24/10/2017 10:31 AM, Kagamin wrote:
> On Tuesday, 24 October 2017 at 07:29:08 UTC, Satoshi wrote:
>> If we want to use D for GUI development we will need this feature anyway.
> 
> To not block UI you need non-blocking IO, and async/await is not required for it: vibe provides non-blocking IO with synchronous interface. And here we also have another shortcoming of async/await: it doesn't interact well with GUI that traditionally uses synchronous event handlers (mostly because it predates async/await).

Just a random idea, something to think about:

```
struct Task {
	void delegate() del;
	void* stack;
	Status status = Status.finished;

	void continue() { del(); }
}

() {
	size_t lastJump;
	if (lastJump == J1) { lastJump=J2; jmp J2; }
	else lastJump = J1;

	J1:
	ubyte[] gotRead = doRead(__task, "...");

	yield;
	J2:

	gotRead /= 2;
	doWrite(__task, "...", gotRead);

	complete; // yield if wasn't done
}
```

From:

```
ubyte[] doRead(string name) async { ... }
void doWrite(string name, ubyte[] data) async { ... }

void callback(...) {
	ubyte[] gotRead = doRead("...");
	gotRead /= 2;
	doWrite("...", gotRead);
}
```

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.

On 10/24/2017 1:13 AM, Satoshi wrote:
> But it's quite useless to me.

That's what interfaces are for. Define your View and Button as interfaces. The implementations of interfaces are completely hidden from the derived class.


> But the worst part is that I need to hold di in sync to d files manually, so there is not any advantages over C++'s header files.

dmd will generate the .di files for you with the -Hd switch. But I suggest using interfaces instead, which look ideal for your application.

On Tuesday, 24 October 2017 at 10:20:43 UTC, Walter Bright wrote:
> On 10/24/2017 1:13 AM, Satoshi wrote:
>> But it's quite useless to me.
>
> That's what interfaces are for. Define your View and Button as interfaces. The implementations of interfaces are completely hidden from the derived class.

Can you provide an example?

On Monday, 23 October 2017 at 21:42:03 UTC, Atila Neves wrote:
> On Monday, 23 October 2017 at 21:14:18 UTC, bauss wrote:
>> On Monday, 23 October 2017 at 12:48:33 UTC, Atila Neves wrote:
>>> On Monday, 23 October 2017 at 09:13:45 UTC, Satoshi wrote:
>>>> On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
>>>>> [...]
>>>>
>>>> Whats about this one?
>>>>
>>>> auto foo = 42;
>>>> auto bar = "bar";
>>>> writeln(`Foo is {foo} and bar is {bar}`);
>>>
>>> writeln("Foo is ", foo, "and bar is ", bar");
>>>
>>> Two more characters.
>>>
>>> Atila
>>
>> Okay, but what about now?
>>
>> void sendAMessage(string message)
>> {
>>     ....
>> }
>
> sendAMessage(text(...));
>
> Atila

But that goes against what you just said with "4 characters more" since text is 4 characters. It's also an extra import which you could avoid with string interpolation.