On 30/11/2022 9:30 PM, Walter Bright wrote:
> On 11/28/2022 6:46 PM, rikki cattermole wrote:
>> Seriously, 2-3 days an actual dmd compiler dev could probably get ModuleInfo exportation on Windows working correctly and we could get shared library support in D starting to actually be decent.
> 
> I looked at https://issues.dlang.org/show_bug.cgi?id=22367 in your list, and the solution appears to be straightforward. I outlined it in the issue. Anyone want to have a go at it?

This isn't fixing it.

Its playing whack-a-mole on symptoms and making it that much harder to verify that DllImport was fixed satisfactorily.

On Wed, Nov 30, 2022 at 12:13:52PM +0000, Paulo Pinto via Digitalmars-d wrote:
> On Wednesday, 30 November 2022 at 01:09:03 UTC, H. S. Teoh wrote:
[...]
> > And to elaborate a little, for those people who groan at "yet another library type": a common objection is that a library type has poorer error messages.  Well, it's just the same thing in different clothes: if a library type can't have good error messages, why is that?  Because the language cannot express certain things, or can't do it well, so the library author's hands are tied.  Giving up and pushing the type into the language is merely avoiding the problem (now the compiler writer has to solve the same problems, only in the compiler -- the amount of effort required is equivalent).  What actually addresses the problem is: fix the language so that the library author *can* provide good error messages.
> > 
> > Because this isn't just about adding sumtype or whatever other magic type, this is about making it possible for *any* user type to provide the same level of functionality as built-in types.  It's about empowering the library writer so that he can replicate the power of a built-in type, integrated so well into the language that it feels like native type.  This includes containers that behave like built-in arrays, ARC'd types that behave like pointers, etc.. Solve this at the core, and it will enable progress on many other fronts.  Fail at this, and you're doomed to putting out individual fires one by one, ala whack-a-mole.  Today it's sumtypes, tomorrow it's ARC types, the next day it's head-immutable, it will never end.
[...]
> We already have C++ for that, beware of having wishes coming true.

Yes and no.  C++ does let you customize all sorts of things (including dangerous things like unary `operator&`, `operator,`, and other such things that *really* mess with program syntax), but it does so in an unclean, non-orthogonal way that gives you 1 way to solve your problem plus 10 other ways of shooting your foot.

Take for example overloading the comparison operators.  Instead of D's much saner approach of having a single opCmp that ensures consistency between <, <=, >=, >, C++ lets you overload each of those operators separately.  As a result, library code has tons of boilerplate (you need
>=4 operator overload functions instead of just a single opCmp), is
fragile (the compiler does not help you maintain consistency between operator<, operator<=, operator>=, and operator>=), and wide open for abuse (I can, for example, write operator< to be an input operator and operator> to format your hard disk).

In the meantime, nothing lets user code dictate how a custom type / function should behave in the face of Koenig lookup + SFINAE, a nasty combination where in order to understand which overload just got called, you have to understand the entire codebase (an impossible task in a large project).

IOW, C++ lets you customize everything, yes, but it does so in the least optimal, most fragile, unorthogonal, and unmaintainable way.

What D needs is hooks into core semantics in the pattern of opEquals/opCmp, not in the pattern of C++'s operator==, operator!=, operator<, operator<=, ad nauseum.  This requires careful thought and design, not just blindly going "oh user code wants to overload the comma operator? sure, just add operator,() and you're all set!" or "oh user code wants to override const? sure, why not introduce operator const() to the language".  The user should be empowered, yes, but with a properly-designed tool, not a lit bundle of dynamite with which to blow himself up.


T

-- 
If it breaks, you get to keep both pieces. -- Software disclaimer notice

On 11/30/2022 6:50 AM, rikki cattermole wrote:
> On 30/11/2022 9:30 PM, Walter Bright wrote:
>> On 11/28/2022 6:46 PM, rikki cattermole wrote:
>>> Seriously, 2-3 days an actual dmd compiler dev could probably get ModuleInfo exportation on Windows working correctly and we could get shared library support in D starting to actually be decent.
>>
>> I looked at https://issues.dlang.org/show_bug.cgi?id=22367 in your list, and the solution appears to be straightforward. I outlined it in the issue. Anyone want to have a go at it?
> 
> This isn't fixing it.
> 
> Its playing whack-a-mole on symptoms and making it that much harder to verify that DllImport was fixed satisfactorily.
> 

I don't know what you mean. It fixes the problem in 22367.

On 01/12/2022 9:38 AM, Walter Bright wrote:
>> This isn't fixing it.
>>
>> Its playing whack-a-mole on symptoms and making it that much harder to verify that DllImport was fixed satisfactorily.
>>
> 
> I don't know what you mean. It fixes the problem in 22367.

The symptom is that dmd is turning on requirement for ModuleInfo when it shouldn't.

The problem is that we can't turn on ModuleInfo generation via a switch.

We can't turn on ModuleInfo generation because it is not exported.

We can't export it due to DllImport being incomplete.



If we can turn on ModuleInfo generation it too fixes this bug.

Please repost your critique on 22367, so others interested in the ModuleInfo issue can see it, as this thread is about sumtypes.

I will respond there.

Thanks!