July 16

On Friday, 16 July 2021 at 09:06:26 UTC, Alexandru Ermicioi wrote:

>

On Wednesday, 14 July 2021 at 15:01:05 UTC, Rune Morling wrote:

>

Hi All,
...
Comments very welcome.

What about making those attributes not just prefixed with @, but fully fledged UDA?
From the point of view of compile time code this would remove the necessity in strange syntax for is expression to get them. You'd just fetch them as any other uda.
Also this will allow us to extend these attributes with fields!
Say for example: @safe(disabled.yes)
Older compiler would just ignore this, but newer could take hints and other additional info defined on these udas for better optimization, or improved checks, or just for informational purposes.
Another example: @deprecated("See xxx for this functionality")

Best regards,
Alexandru.

I absolutely agree! I started writing a longer post on exactly this topic, but you beat me to it :P

July 16

On Friday, 16 July 2021 at 09:06:26 UTC, Alexandru Ermicioi wrote:

>

On Wednesday, 14 July 2021 at 15:01:05 UTC, Rune Morling wrote:

>

Hi All,
...
Comments very welcome.

What about making those attributes not just prefixed with @, but fully fledged UDA?
From the point of view of compile time code this would remove the necessity in strange syntax for is expression to get them. You'd just fetch them as any other uda.
Also this will allow us to extend these attributes with fields!
Say for example: @safe(disabled.yes)
Older compiler would just ignore this, but newer could take hints and other additional info defined on these udas for better optimization, or improved checks, or just for informational purposes.
Another example: @deprecated("See xxx for this functionality")

Best regards,
Alexandru.

And make attributes symbols:

template Pure(bool con){
	import std.meta : AliasSeq;

	static if(con)
		alias Pure = pure;     //this is not valid
	else
		alias Pure = AliasSeq!();	
}

//conditional atributes:

void foo()@(Pure!true){   //expand to `pure`

}

void bar()@(Pure!false){   //expand to `()`

}

July 16

On Friday, 16 July 2021 at 10:17:39 UTC, vit wrote:

>

And make attributes symbols:

If they are UDA, then they are symbols.
I.e in object.d you'd have struct defs for each lang defined attribute:

struct safe {...}
struct nogc {...}
struct deprecated {...}

This consequently means that you can employ them in a template like in your example, or ctfe function that is put as an annotation:

void textedDeprecate(T...)(T args) {
  return deprecated(text(args));
}

@textedDeprecate("this is obsolete since ", 1.0)
struct Obsolete {
}
July 16

On Friday, 16 July 2021 at 09:06:26 UTC, Alexandru Ermicioi wrote:

>

...

To add one more strong point on making them uda:

Suppose that you have a collection interface Collection(T). In order to make it portable and usable in safe pure or nogc code, the methods in collection should infer the properties of stored entities. This is not possible at the moment since you can't define these attributes based on a condition. However, if you make them UDA this means that you can create templates that check the capabilities of the stored entities and alias itself to the supported tuple of features, say Foo is safe but nogc, then instantiation of collection will become @safe Collection!Foo, while for nogc but unsafe Noo struct it will become @nogc Collection!Noo.

Regards,
Alexandru.

July 17

On Wednesday, 14 July 2021 at 15:01:05 UTC, Rune Morling wrote:

>

Comments very welcome.

I just noticed there is an issue for this:
https://issues.dlang.org/show_bug.cgi?id=13388

And a discussion:
https://forum.dlang.org/post/rtwbtxigfeupvykpbamh@forum.dlang.org

And a PR that got merged:
https://github.com/dlang/dmd/pull/4341

But reverted because there was no consensus in the discussion yet:
https://github.com/dlang/dmd/pull/4349

July 18

On Wednesday, 14 July 2021 at 15:01:05 UTC, Rune Morling wrote:

>

The current DIP draft can be found here.

I support using built-in @attributes when they only affect functions, not parameters, variables or fields. This would mean only a few minor additions to increase consistency. For this we need to add @override, @abstract, @final ('@final class' only affects a class's methods, not field members) to the DIP.

July 18

On Friday, 16 July 2021 at 06:47:57 UTC, bauss wrote:

> >

I don't like that @attr is colliding with UDA.
It would be nice to have # for attr and @ for uda (or viceversa).

I would rather have seen built-in attributes having no prefix ex. just safe, nogc etc.

Basically the opposite of making the rest of the attributes having @ too.

+10.447464

More syntax was fine when the attributes were new, but it seems to me what is needed would be more "normalcy": safe, trusted, nogc
If you're calling your variable safe or nogc, then well they are now keywords: choose proper names.

July 21

On Saturday, 17 July 2021 at 10:51:20 UTC, Dennis wrote:

>

On Wednesday, 14 July 2021 at 15:01:05 UTC, Rune Morling wrote:

>

Comments very welcome.

I just noticed there is an issue for this:
https://issues.dlang.org/show_bug.cgi?id=13388

And a discussion:
https://forum.dlang.org/post/rtwbtxigfeupvykpbamh@forum.dlang.org

And a PR that got merged:
https://github.com/dlang/dmd/pull/4341

But reverted because there was no consensus in the discussion yet:
https://github.com/dlang/dmd/pull/4349

Thank you for the investigation and for listing the prior discussions.

I've read all of it and the most pertinent summary of the situation I could find was this:

>

The problem is that no proposal has been given which really makes the attribute names
consistent in a way that makes sense to actually change to.
We may agree that the status quo is ugly, but how things should be changed is not
at all clear. So, we don't even know how we'd want to change the language to fix
the attribute situation.

And even if dfix makes it easy to change code, breaking code still causes problems.
So, while dfix will definitely help reduce the pain when we do decide to make changes
to the language which will require changing existing code, it doesn't make the language
changes free. The fact that dfix could make it easy to change existing code does not
mean that it's okay to make breaking changes without a very good reason behind them.

source

In other words, unless I/we can come up with an "algorithm" for deciding when something should be an @-attribute, the DIP I've proposed has little merit in that it's basically just proposing that we shuffle attributes around on a whim.

Personally, I'm currently leaning towards something that describes how a keyword/attribute changes the amount of checks that the compiler makes so that it's akin to switching to a different "mode" of compilation with attendant extra/fewer checks/limits on functions.

July 21

On Sunday, 18 July 2021 at 09:50:30 UTC, Nick Treleaven wrote:

>

On Wednesday, 14 July 2021 at 15:01:05 UTC, Rune Morling wrote:

>

The current DIP draft can be found here.

I support using built-in @attributes when they only affect functions, not parameters, variables or fields. This would mean only a few minor additions to increase consistency. For this we need to add @override, @abstract, @final ('@final class' only affects a class's methods, not field members) to the DIP.

In keeping with my last post, what is your proposed reasoning for using @override, @abstract and @final (= making them @-attributes)?

As I see it, @nogc, @nothrow, @pure and @safe all define that something out of the ordinary or special is happening on a language/compiler "meta-level" rather than being directly associated with/derived from with class/type hierarchy functionality?

My take:

  • 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)

Can you help me understand what I might be missing here?

July 21

On Wednesday, 21 July 2021 at 20:00:32 UTC, Rune Morling wrote:

>

In other words, unless I/we can come up with an "algorithm" for deciding when something should be an @-attribute, the DIP I've proposed has little merit in that it's basically just proposing that we shuffle attributes around on a whim.

Here's my take.

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

  1. The Type Constructor Group: const, immutable, inout, and shared.
  2. The Inheritance Group: final, override, and abstract.
  3. The Visibility Group: public, private, protected, package, and export.
  4. 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.

1 2 3 4