On Friday, 28 July 2017 at 01:50:24 UTC, Jonathan M Davis wrote:
> Should public have @ on it? Should static have @ on it? What about scope, const, or shared?

If they are storage classes, they shouldn't have @. If they are statement or expression keywords, they shouldn't have @. Things like that are introduced with leading underscores: __traits, __gshared.

public etc could be @ attributes, but I see no reason to change them. This inconsistency can be explained by just saying visibility is special. (That said I wouldn't complain if they were changed too). Common keywords in other languages can help justify keeping those keywords in D.

> it looks like the DIP is talking about what the default attributes in general are. It's one thing to slap a default set of attributes at the top of a module and then negate them later in the module

This is one part of the DIP I like - `@safe module foo;`. AIUI this would enable a @safe default that doesn't stop code such as templates being inferred as @system. This is not currently possible in D. I know Walter has talked about inferring attributes for all function bodies - in that case the DIP seems a bit less useful, but could still set the default for unittests, module ctors/dtors and main().

On Friday, 28 July 2017 at 11:45:21 UTC, Nick Treleaven wrote:
> On Friday, 28 July 2017 at 01:50:24 UTC, Jonathan M Davis wrote:
>> Should public have @ on it? Should static have @ on it? What about scope, const, or shared?
>
> If they are storage classes, they shouldn't have @. If they are statement or expression keywords, they shouldn't have @. Things like that are introduced with leading underscores: __traits, __gshared.
>
> public etc could be @ attributes, but I see no reason to change them. This inconsistency can be explained by just saying visibility is special. (That said I wouldn't complain if they were changed too). Common keywords in other languages can help justify keeping those keywords in D.

the only catch there is that the `package` visibility takes an optional module following it and therefore can't be done as an enum.

>> it looks like the DIP is talking about what the default attributes in general are. It's one thing to slap a default set of attributes at the top of a module and then negate them later in the module
>
> This is one part of the DIP I like - `@safe module foo;`. AIUI this would enable a @safe default that doesn't stop code such as templates being inferred as @system. This is not currently possible in D. I know Walter has talked about inferring attributes for all function bodies - in that case the DIP seems a bit less useful, but could still set the default for unittests, module ctors/dtors and main().

Hmm, after some discussions in this thread I decided that it would be better to have a "last applied wins" rule so as not to need the whole tag the module decl to set the default for the module. I suppose it could be bought back if need be but it's kind of redundant with "last applied wins". Templates may still be a bit of a problem.

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:
> DIP 1012 is titled "Attributes".
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md
> Thanks in advance to all who participate.
>
> Destroy!

My primary points

* Don't formally deprecate the keywords, there is not enough justification to ever remove them.
* Remove the whole program defaults, I'm ok with it being changed in a re-implementation of the runtime (like the embedded example), we just don't need the extra confusion within user code.
* Specifying inferred needs to be within druntime only, and thus may not need to exist.
* I'm concerned user defined attributes could define a "defaults" for functions.

I think the updated document needs some additional rework, here are some examples:

# Rational

A number of issues with the existing functional attribute system have come up through the years.

* Certain attributes don't have a name, e.g. All functions ''throws'' but this is not an existing attribute.
* The default attributes were not correctly chosen, e.g. all class methods should be ''final'' unless specified otherwise, and because of the first point declaring 'final:' at the top of the class cannot be undone.
* AliasSeq is provided to manage Attributes, but it doesn't handle built in attributes (I could be wrong but is what I'm getting from the document even though it isn't explicitly stated)
* ...

# Description

Function existing attributes and their unnamed counterpart will exist as an enum within core.attributes. This module will be implicitly imported to provide the symbols without explicit import or breaking existing code. The compiler will recognize the non-@ based attributes as the corresponding core.attribute.

...

## Implementation Details

----------
module core.attribute;

enum Protection {
system,
safe,
trusted,
}

alias safe = Protection.safe;
...
-----------

The compiler will default functions to the first value of the enum [for my example].

[So on and so forth]

On Friday, 28 July 2017 at 21:47:32 UTC, Jesse Phillips wrote:
> On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:
>> DIP 1012 is titled "Attributes".
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md
>> Thanks in advance to all who participate.
>>
>> Destroy!
>
> My primary points
>
> * Don't formally deprecate the keywords, there is not enough justification to ever remove them.

Indeed the only reason for removing them would be to remove code from the compiler. They do no harm at all.

> * Remove the whole program defaults, I'm ok with it being changed in a re-implementation of the runtime (like the embedded example), we just don't need the extra confusion within user code.

The program defaults are there to make @safe by default a thing, and betterC by default a thing, which are covered in the _three Primary points_ of the semesters Vision document[1]. These would not normally be set (i.e. opt in).

> * Specifying inferred needs to be within druntime only, and thus may not need to exist.

I think there is usefulness in having it, particularly as the meta-default (defaultAttributeSet). Walter has ben pushing for some time to infer attributes by default. This would provide a directive for the compiler to do so. Please elaborate.

> * I'm concerned user defined attributes could define a "defaults" for functions.

you mean user UDAs (if not please explain)? the default application of UDA is for core attributes only.

>
> I think the updated document needs some additional rework, here are some examples:
>
> # Rational
>
> A number of issues with the existing functional attribute system have come up through the years.
>
> * Certain attributes don't have a name, e.g. All functions ''throws'' but this is not an existing attribute.
> * The default attributes were not correctly chosen, e.g. all class methods should be ''final'' unless specified otherwise, and because of the first point declaring 'final:' at the top of the class cannot be undone.
> * AliasSeq is provided to manage Attributes, but it doesn't handle built in attributes (I could be wrong but is what I'm getting from the document even though it isn't explicitly stated)
> * ...
>
> # Description
>
> Function existing attributes and their unnamed counterpart will exist as an enum within core.attributes. This module will be implicitly imported to provide the symbols without explicit import or breaking existing code. The compiler will recognize the non-@ based attributes as the corresponding core.attribute.
>
> ...
>
> ## Implementation Details
>
> ----------
> module core.attribute;
>
> enum Protection {
> system,
> safe,
> trusted,
> }
>
> alias safe = Protection.safe;
> ...
> -----------
>
> The compiler will default functions to the first value of the enum [for my example].

( That would provide a pessimistic default and debates the ability for the compiler to infer)
>
> [So on and so forth]

Thanks for your suggestions.

[1]: https://wiki.dlang.org/Vision/2017H2

On Friday, 28 July 2017 at 23:25:35 UTC, Nicholas Wilson wrote:
> On Friday, 28 July 2017 at 21:47:32 UTC, Jesse Phillips wrote:
>> * Remove the whole program defaults, I'm ok with it being changed in a re-implementation of the runtime (like the embedded example), we just don't need the extra confusion within user code.
>
> The program defaults are there to make @safe by default a thing, and betterC by default a thing, which are covered in the _three Primary points_ of the semesters Vision document[1]. These would not normally be set (i.e. opt in).

I read that as more, Improve Druntime and phobos's us of @safe so that it becomes more usable.

>> * Specifying inferred needs to be within druntime only, and thus may not need to exist.
>
> I think there is usefulness in having it, particularly as the meta-default (defaultAttributeSet). Walter has ben pushing for some time to infer attributes by default. This would provide a directive for the compiler to do so. Please elaborate.

I don't expect inference to happen outside templates. Besides if the compiler infers the appropriate attributes by default, isn't 1. a default attribute redundant and 2. specifying inference redundant as the compiler defaults to inferring?

>> * I'm concerned user defined attributes could define a "defaults" for functions.
>
> you mean user UDAs (if not please explain)? the default application of UDA is for core attributes only.

Yes I'm User's UDA (user defined attributes). I expected it wouldn't apply outside the context of core.attributes.


>> The compiler will default functions to the first value of the enum [for my example].
>
> ( That would provide a pessimistic default and debates the ability for the compiler to infer)

Yes, just throwing in an example structure and why I mentioned [for my example]. But as said earlier infer and default are at odds.

>> [So on and so forth]
>
> Thanks for your suggestions.
>
> [1]: https://wiki.dlang.org/Vision/2017H2

On Monday, 31 July 2017 at 19:27:46 UTC, Jesse Phillips wrote:
> On Friday, 28 July 2017 at 23:25:35 UTC, Nicholas Wilson wrote:
>> On Friday, 28 July 2017 at 21:47:32 UTC, Jesse Phillips wrote:
>>> * Remove the whole program defaults, I'm ok with it being changed in a re-implementation of the runtime (like the embedded example), we just don't need the extra confusion within user code.
>>
>> The program defaults are there to make @safe by default a thing, and betterC by default a thing, which are covered in the _three Primary points_ of the semesters Vision document[1]. These would not normally be set (i.e. opt in).
>
> I read that as more, Improve Druntime and phobos's us of @safe so that it becomes more usable.

Improving druntime and phobos is obviously important, but so is the ability for the end user to use it. If its hard to use less people will use it, conversely the easier it is the more likely people are to use it. Not that this also provides an easy way to find out which function are not @safe and fix them, without slapping @safe on main, i.e. build unit (package/library) at a time.

>>> * Specifying inferred needs to be within druntime only, and thus may not need to exist.
>>
>> I think there is usefulness in having it, particularly as the meta-default (defaultAttributeSet). Walter has ben pushing for some time to infer attributes by default. This would provide a directive for the compiler to do so. Please elaborate.
>
> I don't expect inference to happen outside templates. Besides if the compiler infers the appropriate attributes by default, isn't 1. a default attribute redundant and 2. specifying inference redundant as the compiler defaults to inferring?

It happens already for dip1000 IIRC and I be surprised if, particularly for @safe, Walter didn't want more inference. Especially for minimal user effort.

>>> The compiler will default functions to the first value of the enum [for my example].
>>
>> ( That would provide a pessimistic default and debates the ability for the compiler to infer)
>
> Yes, just throwing in an example structure and why I mentioned [for my example]. But as said earlier infer and default are at odds.

I disagree. Even if infer wasn't the default I would certainly like to be able to have them be inferred at the flick of a compiler switch. It goes back to the ease of use argument, its more effort for me to manually annotate things.

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:
> DIP 1012 is titled "Attributes".
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md
>
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on August 10 (3:59 AM GMT August 11), or when I make a post declaring it complete.

I don't know what's happening with this DIP, but I've recently encountered a real-world problem for which there is no palatable workaround that this DIP would likely solve:

https://github.com/dlang/druntime/pull/2184#pullrequestreview-120643123

My attempts to workaround the issue I posted at
https://forum.dlang.org/post/uhgzgmowqcczczrdtsol@forum.dlang.org

That PR may be useful for motivating this DIP.

Mike

On Sunday, 27 May 2018 at 13:44:40 UTC, Mike Franklin wrote:
> I don't know what's happening with this DIP, but I've recently encountered a real-world problem for which there is no palatable workaround that this DIP would likely solve:
>
> https://github.com/dlang/druntime/pull/2184#pullrequestreview-120643123
>
> My attempts to workaround the issue I posted at
> https://forum.dlang.org/post/uhgzgmowqcczczrdtsol@forum.dlang.org
>
> That PR may be useful for motivating this DIP.
>
> Mike

It looks like all you need is a way to toggle attributes with a flag, like pure(isPure) or something.  IIRC, last time that came up, it turned into a bikeshedding fest about the syntax.  (I don't think parentheses works with UDAs.)  Anyway, yeah, we need the functionality.

However, this DIP is *way* more complicated.  I stand by what I said before: https://forum.dlang.org/post/dnmcqwkdfmommiiugcvv@forum.dlang.org  Jonathan M Davis said it in long form: https://forum.dlang.org/post/mailman.5429.1501206646.31550.digitalmars-d@puremagic.com

The proposal says that builtin attributes are replaced by UDAs defined in the runtime. But user-defined attributes don't work like @safe, @system, and @trusted:

---
struct Attr {}
@Attr @safe:
class Foo
{
  // this function is @safe but not @Attr
  void doStuff() {}
}
---

In order to make the proposal work as intended, in a backwards-compatible way, the attributes in core.attributes need to be able to specify whether they descend into nested declarations or not.

It would be handy for arbitrary user-defined attributes to be able to specify this, too.