On 15/06/2023 2:44 PM, Chris Katko wrote:
> imported std.regex? You just doubled your compile time. There's a gotcha.

That is more or less solved.

https://github.com/dlang/phobos/pull/8699

On 6/8/2023 10:20 AM, Johan wrote:
> - Intentional change of behaviour, sometimes without clear solution path or with buggy solutions. https://issues.dlang.org/show_bug.cgi?id=23966 and 23977 for recent examples.

I suggest:

Restore the old getAttributes behavior, and create a new getAttributes2 with the new behavior.

Will that work for you?

On 6/9/2023 2:22 AM, GrimMaple wrote:
> The better way has been proposed already, it's just being dismissed without consideration. What is your take, what will allow us to have an LTS branch?

It's come up before many times, it's not like we haven't considered it.

We actually do have it - we do major releases, and point releases. Into the point releases go regression fixes and critical bug fixes.

The trouble, though, is we simply don't have the staff to do a whole lot with this.

On Thursday, 15 June 2023 at 04:18:34 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 15/06/2023 2:44 PM, Chris Katko wrote:
>> imported std.regex? You just doubled your compile time. There's a gotcha.
>
> That is more or less solved.
>
> https://github.com/dlang/phobos/pull/8699

That's great news!

On Thursday, 15 June 2023 at 07:07:18 UTC, Walter Bright wrote:
> Restore the old getAttributes behavior, and create a new getAttributes2 with the new behavior.
>
> Will that work for you?

This is often even worse than just changing the original, so such things need to be evaluated on a case-by-case basis.

For the case of getAttributes, there's nothing actually wrong with the original behavior! The proposed getAttributes2 would be exactly identical to getAttributes, except that it gives a deprecation message on certain (currently ambigously defined, but could easily become defined) uses. There's no benefit to this and it would just add to long-term confusion as new people wonder what the differences are between the two.

(Something similar happened with getVirtualMethods and getVirtualFunctions. One was simply defined incorrectly and instead of fixing it, the other was introduced with a subtly different definition. That one is more justifiable than getAttributes2 would be, since it actually *was* defined, and *maybe* that subtle difference matters, and it is hard for the compiler to statically detect. But now the current result is you have a function that is wrong and a function that is right sitting side by side with only a careful reading of the docs revealing which is which.)

What I would suggest for getAttributes is either:

Option 1: Define its status quo behavior on the spec. If passed an overloaded function symbol, it will return the attributes of the lexically first function in the set. There's nothing actually wrong with that if people know what to expect and how to work with it! Put in the docs: Tip: you can use getOverloads to loop over all the overloads in the set. Optionally, change getOverloads so it also works on non-functions, so you can always loop over names and overloads (Even if a set of one item in the case of non-overloadable entities) without a separate branch.

OR

Option 2 (my preference): Sit down and define what, exactly, an overload set is in the language and make it into its own conceptual model with associated definitions in the reflection system. I don't have a specific proposal for D right now, but in my little script.d language, I made overload sets actually be an object with opCall defined. This is, of course, different since script.d is a dynamic language so many things, including overload resolution, happen at runtime. Indeed, this design was less about conceptual purity than about laziness in implementation - I already had objects and opCall working, so defining an object that internally had an array of functions and dispatched it was fairly easy.

But a side effect is the rest of the language can still work with it. I can loop over the overloads by... just literally looping over the overload set member in the object. You can detect it is an overload set by comparing object types. Other properties can be attached to it, etc.

That exact implementation is not right for D, but perhaps something similar could work. We could define all kinds of things in both the docs and in the language, iron out some edge cases, and make reflection easier to use.


You might even do both of these options, #1 in the short term, and #2 as part of a complete overhaul of the reflection system. Our random collection of of traits has served D well so far, but a second draft can learn a lot from its real world lessons and then both would exist side by side as a compatibility bridge.

On Thursday, 15 June 2023 at 02:44:59 UTC, Chris Katko wrote:
> Tell any other object about yourself in the constructor? segfault. Because your object isn't constructed till _after_ the constructor runs. There's a gotcha.

What case triggers this? I've heard of most the other things but this one I can guess a couple things on but I'm not sure.

> Not adding a feature I can use like [private] for classses (if I understand correctly, they don't do anything in D)

The `private` keyword always applies on the module level, so a private class member can be seen inside its module but not outside it.