https://docs.google.com/document/d/1bh-oho1vNpGpK7jaaBgitkV3fOY_but9oUQm5ObpQAQ/edit?usp=sharing

Destroy!

On Wednesday, 5 February 2025 at 02:39:18 UTC, 12345swordy wrote:

Seems mostly reasonable, though there are a lot of details that will need to be filled in for future drafts.

Some small suggestions:

I assume "can't not" is an editing mistake, and what you mean is "can't."

It would be much simpler to just say, "you can't take the address of a @property function."

I know what you mean by this, but in future drafts you will need to actually spell out the exact rules, for both getters and setters.

This is how it already works, right? It's a little confusing to mix together new features and ones that already exist in the same list.

Same here--inout paramters already accept (the return values of) @property functions, just like they accept the return values of any other function.

On Wednesday, 5 February 2025 at 02:39:18 UTC, 12345swordy wrote:

Please use GitHub and, even more important, use Markdown or something that makes code look like code.

Your Draft is not a draft. It’s an outline for an idea. The correct forum for ideas is the DIP Ideas. A DIP draft should be such that if it happened to be perfect, it could go to formal assessment. Your document doesn’t even have the right structure to qualify as a DIP. You propose no actual changes and there are no examples, which is why I said “outline for an idea” instead of just “idea.” Have a look at other ideas and drafts to get a feeling for what is expected. What you currently have, I would have put in the General forum because it essentially asks the community to forge the outline into an actual idea.

• Outline: States design goals, problems
• DIP Idea: States an abstract design, not fleshed out completely.
• DIP Draft: Formal document with all required sections, detailed design, ideally accompanied with an implementation.

Quotes are from the document.

I don’t see how CTFE and properties are specially linked.

That’s not a design. You’re stating the goals for a design, but the document does not include a design.

You talk about wrappers a lot, but I fail to see how wrappers are related to properties.

On Wednesday, 5 February 2025 at 02:39:18 UTC, 12345swordy wrote:

This!

I just suggest to change (fix?) some wording:

"Currently properties are in a limbo state as the introduction of compile time function evaluation (CTFE) has made the purpose of properties redundant in the view of many programmers. However this paper argues that the CTFE can not replace the purpose of first class abstraction for types as it currently have the following issues:"

"The common argument against properties is to make it part of a library instead of a language feature."

"You can not take the address of the property (at least not without using the traits via reflection)"

"It can not be passed as a function to a parameter/type (at least not without using the traits system to obtain said function). This is to make sure that it is used as the type that it is abstracted for."

Additionally I would add something like:

"One important reason to provide properties as language feature is to give the programmer more fine grained control over what can be done with some member of a type (reading, writing, getting the address)."

On Wednesday, 5 February 2025 at 13:37:11 UTC, Quirin Schroll wrote:

I am using google docs as it the most convenient way of expressing my proposal here. There is no mention of having to use markdown here in DIP Forum Guidelines and I already post it in the discord server and no one object to the format that I picked.

Of course it is. A first draft doesn't need be perfect in order be a draft.

Regardless, I had been informed via email regarding the new dip process, that I should post the idea before I pursuit it. It been quite a long time sense I posted here. I will do that next time.

...It is Literally in the title!

On Wednesday, 5 February 2025 at 16:29:00 UTC, 12345swordy wrote:

Welp that age like a glass of milk. I didn't know that having a markdown document is a requirement not suggestion via email with Michael Parker. Will get right to it.