July 21

On Wednesday, 21 July 2021 at 20:46:01 UTC, Paul Backus wrote:

>

Here's my take.

D's attributes can be divided, conceptually, into a few different "groups" of related attributes. Some examples are:

(...)

  1. The Function Attribute Group: pure, nothrow, @nogc, @safe, @system, @trusted, @property, and @live.

...and so on.

The rule I propose is that within a single group, use of @ should be consistent--either all of the attributes should use it, or none of them should.

Of course this invites some debate as to where exactly one ought to draw the group boundaries (e.g., should @property be counted as part of the function attribute group, or is it a separate thing?). But it is at least a step forward from the current discussion, which does not even acknowledge that these groups exist in the first place.

I like this approach.

Consider the idea internally consistent groups acknowledged.

For the current DIP to go anywhere, we'd probably need to agree/converge on how to divide all attributes into a reasonable set of groups?

Once we have that, we can then discuss inter-group consistency and propose the relevant changes.

What other group distinctions would make sense (if any)?

July 21

On Wednesday, 21 July 2021 at 22:43:49 UTC, Rune Morling wrote:

>

For the current DIP to go anywhere, we'd probably need to agree/converge on how to divide all attributes into a reasonable set of groups?

If the proposal is just to allow @pure and @nothrow (and @throw, once DIP 1029 [1] is implemented), I think it would probably be sufficient to make the case that the function attributes form a distinct group.

[1] https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1029.md

>

Once we have that, we can then discuss inter-group consistency and propose the relevant changes.

What other group distinctions would make sense (if any)?

As far as I know, the only groups that include both @ and non-@ attributes are (1) the function attributes, and (2) the group consisting of deprecated and @__future.

3 days ago

On Wednesday, 21 July 2021 at 20:13:16 UTC, Rune Morling wrote:

>
  • abstract says something about the type of a class/function (part of the OOP hierarchy)
  • final says that a function in a class cannot be overridden (part of the OOP hierarchy)
  • override says that a function in a class is being overridden (part of the OOP hierarchy)

None of these 3 attributes change the actual type of the class, they only affect methods in the class or methods in a subclass. What I'm saying is that it's simpler and easier to remember to use @attribute syntax for attributes that only affect a function/method, rather than that rule except attributes that are related to OOP don't use @.

Really using abstract class or final class is just another way of writing class Foo {final: ... or class Foo {abstract: .... So the attributes actually apply to the methods.

2 days ago

On Monday, 26 July 2021 at 12:07:01 UTC, Nick Treleaven wrote:

>

Really using abstract class or final class is just another way of writing class Foo {final: ... or class Foo {abstract: .... So the attributes actually apply to the methods.

Not sure about final modifier. By your definition you would be able to extend a final class, which is not right.

Next ›   Last »
1 2 3 4