September 19, 2018
On 19/09/2018 1:49 PM, Jonathan M Davis wrote:
> On Tuesday, September 18, 2018 6:22:55 PM MDT Manu via Digitalmars-d wrote:
>> On Mon, 17 Sep 2018 at 06:00, Atila Neves via Digitalmars-d
>>
>> <digitalmars-d@puremagic.com> wrote:
>>> On Sunday, 16 September 2018 at 17:46:26 UTC, Steven
>>>
>>> Schveighoffer wrote:
>>>> On 9/14/18 6:41 PM, Neia Neutuladh wrote:
>>>>> Specifically, Walter wants this to compile:
>>>>>
>>>>> module whatever;
>>>>> extern(C++, foo) void doStuff();
>>>>> extern(C++, bar) void doStuff();
>>>>>
>>>>> And he's not too concerned that you might have to use doubly
>>>>> fully qualified names to refer to C++ symbols, like:
>>>>>
>>>>> import core.stdcpp.sstream;
>>>>> import core.stdcpp.vector;
>>>>> core.stdcpp.vector.std.vector v;
>>>>
>>>> This is probably the best explanation of why the current
>>>> situation sucks.
>>>>
>>>> -Steve
>>>
>>> Agreed. Up until now, I didn't even understand the rationale for
>>> why it works the way it does.
>>
>> https://github.com/dlang/dmd/pull/8667
>>
>> O_O
>>
>> Thank you Walter for coming to the party!
> 
> Oh, wow. I sure wasn't expecting that. I thought that he'd made it pretty
> clear that a DIP was needed, and even then, it didn't seem likely that it
> would be accepted. This is awesome. I guess that he finally came around.
> 
> - Jonathan M Davis

Indeed, thank you Walter!
September 19, 2018
On 9/18/18 9:49 PM, Jonathan M Davis wrote:
> On Tuesday, September 18, 2018 6:22:55 PM MDT Manu via Digitalmars-d wrote:
>> https://github.com/dlang/dmd/pull/8667
>>
>> O_O
>>
>> Thank you Walter for coming to the party!
> 
> Oh, wow. I sure wasn't expecting that. I thought that he'd made it pretty
> clear that a DIP was needed, and even then, it didn't seem likely that it
> would be accepted. This is awesome. I guess that he finally came around.

I think a big part is that the implementation was done. I think there's a big difference between "I don't really love this, but crap, I'll have to implement it all" and "I don't really love this, but the implementation isn't too intrusive, and all I have to do is click the merge button, OK." I sure wish I had the skills to hack dmd, there are so many ideas I'd like to see implemented in the language :)

Anyways, great to see this merged!

-Steve
September 19, 2018
On Wednesday, September 19, 2018 7:26:07 AM MDT Steven Schveighoffer via Digitalmars-d wrote:
> On 9/18/18 9:49 PM, Jonathan M Davis wrote:
> > On Tuesday, September 18, 2018 6:22:55 PM MDT Manu via Digitalmars-d
wrote:
> >> https://github.com/dlang/dmd/pull/8667
> >>
> >> O_O
> >>
> >> Thank you Walter for coming to the party!
> >
> > Oh, wow. I sure wasn't expecting that. I thought that he'd made it
> > pretty
> > clear that a DIP was needed, and even then, it didn't seem likely that
> > it
> > would be accepted. This is awesome. I guess that he finally came around.
>
> I think a big part is that the implementation was done. I think there's a big difference between "I don't really love this, but crap, I'll have to implement it all" and "I don't really love this, but the implementation isn't too intrusive, and all I have to do is click the merge button, OK." I sure wish I had the skills to hack dmd, there are so many ideas I'd like to see implemented in the language :)
>
> Anyways, great to see this merged!

Having an implementation available hasn't always done the trick, but it's certainly easier to try to convince Walter accept something that's already been done than to convince him that he should implement something - which really shouldn't be a surprise. I expect that pretty much all of us are that way.

- Jonathan M Davis



September 19, 2018
On 9/18/2018 5:22 PM, Manu wrote:
> Thank you Walter for coming to the party!

I suppose I should explain this.

1. The PR uses a different syntax, i.e. strings instead of identifiers. This implies it is not creating a scope, and doesn't interfere with the scoping of the existing syntax. The design of the feature is simple and easy to document and understand, and doesn't break anything.

2. Manu and Atila are at the forefront of interfacing with C++. They are both doing massive amounts of work making it work. I'm willing to give a lot of deference to people who know what they are doing and have earned it through their major contributions and longtime membership in our community.

3. The PR for it looks to be a solid piece of work, and even if it turns out otherwise, it's pretty low risk and fixable.

Thanks to Manu, Atila and look-at-me.
September 19, 2018
On Wed, 19 Sep 2018 at 13:15, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 9/18/2018 5:22 PM, Manu wrote:
> > Thank you Walter for coming to the party!
>
> I suppose I should explain this.
>
> 1. The PR uses a different syntax, i.e. strings instead of identifiers. This implies it is not creating a scope, and doesn't interfere with the scoping of the existing syntax. The design of the feature is simple and easy to document and understand, and doesn't break anything.

Wait up, just to be clear... is this a statement about the PR using
strings different than your perception of the conversation surrounding
this?
This PR implements *exactly* what I was calling for literally the same
day that the first patch introducing support was merged however many
years ago, and every few months thereafter...

I'm just curious to know if this PR was somehow surprising to you.
Because if so, it demonstrates a total and colossal failure to
communicate the preferred design of this feature ;)
It was always desired to be a string from day -1, and the bugzilla
issue presented it that way too.
October 10, 2018
On Wednesday, 5 September 2018 at 00:35:50 UTC, Manu wrote:
>>
>> That's all you need really, any symbol you add will cause the error.
>>
>> extern(C++, bliz):
>>
>> created a symbol "bliz", you can't import a package from "bliz" cause then there's a symbol clash. I thought you implemented extern(C++) ...
>
> And yes, the example is actually complete. Again, but I'll simplify the filenames:
>
> ns/bar.d
> -------------
> module ns.bar;
> import ns.baz;
> extern(C++, ns):
>
> ns/baz.d
> -------------
> module ns.baz;
> import ns.bar;
> extern(C++, ns):
>
>
>> dmd ns/bar.d ns/baz.d

I just found this little hack for such situations. It seems like a combined effect of mixin template and normal mixin that seems to work by abusing the creation of temporary module for each instantiation.

The obvious downside is mixin/CTFE being memory hungry and compilation times increase.

Also not sure what happens when there is name clashes due to multiple symbols imported from multiple modules.

Tested with DMD 2.082 -m32mscoff on Windows.

file1.d
```
    mixin template a01() {
     mixin(`
     extern(C++, namespaceone)
     public void fun ();
    `);
    } mixin a01;

    mixin template a02() {
     mixin(`
     extern(C++, namespaceone)
     public void otherfun ();
    `);
    } mixin a02;
    // the rest ....
```

file2.d
```
    mixin template a03() {
     mixin(`
     extern(C++, namespaceone)
     public void yetanotherfun ();
    `);
    } mixin a03;
    // ...
```

1 2 3 4 5 6
Next ›   Last »