Temtaime:

> Too many attributes in D.
> In C++ there is no pure, safe, trusted and others.
>
> And it's C++ that shows that almost all of D attributes are not necessary.

And C shows that most C++ features are not necessary. You can implement OOP manually, etc.

Bye,
bearophile

On Saturday, 21 June 2014 at 18:07:25 UTC, Temtaime wrote:
> And it's C++ that shows that almost all of D attributes are not necessary.

How so?

Anyway, I totally agree that attributes NEED cleanup, it really makes zero sense to have some without "@" annotation. Really, keep Scott's talk in mind! :P

About code breakage: a sane deprecation path and an automated tool to make the code up-to-date will make sure there is zero discomfort for D users.

The alias for the @attribute set seems a very nice syntax to me.

We can try to emulate it, yes. But it results in bug-prone and 'll ugly.
C++ gives more comfortable ways to implement things.

And attributes - it's only restrictions and gives almost nothing.
If you  don't want to play with pointers - just don't do it instead of writing @safe etc.

On Saturday, 21 June 2014 at 18:20:43 UTC, Temtaime wrote:
> And attributes - it's only restrictions and gives almost nothing.

I'll reiterate that the restrictions in question make code easier to reason about. Increased reasoning is not "almost nothing" ... in fact, that's one of the main benefits of having any abstractions at all.

> If you  don't want to play with pointers - just don't do it instead of writing @safe etc.

I think if you'd like a discussion about the values of the various attributes, you should create a topic about it. This topic should really only relate to this DIP.

But FWIW, if what you said was truly sufficient, then there wouldn't be nearly as many bugs in C++ codebases as there are. Furthermore, there wouldn't be D, Go, Rust, Haskell, etc. and/or they wouldn't be found to be valuable by anyone.

Temtaime:

> If you  don't want to play with pointers - just don't do it instead of writing @safe etc.

This is the C approach to programming, that has worked well enough for many years. Give the programmers all the sharp tools and let them sort out their usage and to follow sufficient safety measures. The result is an industry of code verifiers, tight code that runs fast, but sometimes fails very badly.

Another approach is visible in Ada/Rust, safety on default enforced by the type system and the annotations. Ada works very well for its high integrity niche, while Rust is still unproven, but looks promising.

D seems to follow an intermediate route. It's still not as safe as Ada/Rust, but it's somewhat safe and Walter shows that he wants D to become safer in future.

Bye,
bearophile

I think you misunderstood me.
I didn't say that C++ is useless and C can do all the things.
I spoken only about attributes.

D gives much more static checks and other great things.
And i'm unsure only at necessity of all these attributes.

In all my code i really uses only " const ", " immutable " and " @property ".

On 06/21/14 19:56, Shammah Chancellor via Digitalmars-d wrote:
> I like it, but I think the attribute sets should be based on then alias syntax though.
> 
> alias @attributeSet = (@attribute1, @attribute2, @attribute3);

Well, D does not have that kind of tuple syntax and introducing one for this special case wouldn't be a good idea. Other than that, this feature already exists, only it's currently limited to user defined attributes. The present syntax looks like this:

   alias Tuple(A...) = A;
   alias attributeSet = Tuple!(attribute1, attribute2, attribute3);

and is already usable with UDAs and "magic" attributes:

   version (GNU) {
   static import gcc.attribute;
   enum noinline = gcc.attribute.attribute("noinline");
   }

   struct other_attribute {}

   alias Tuple(A...) = A;

   alias spiffy = Tuple!(other_attribute, noinline);

   @spiffy int f(int a) { return a+a; }

I'm not sure inventing another syntax is necessary.

(Making the built-in (keyword) attributes less special is of course
the hard part, but the choice of syntax shouldn't really affect that)

artur

On Sat, 21 Jun 2014 17:54:33 +0000
Peter Alexander via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Saturday, 21 June 2014 at 17:20:08 UTC, Brian Rogoff wrote:
> > I completely agree with your point, but if things never get cleaned up we'll need a guy like Scott Meyers to explain the overcomplicated result. I don't know how to resolve this issue, opponents of change will claim that a language will never get traction if it changes too much too quickly, and proponents will claim that not removing inconsistencies leads to a mess. Both are right.
>
> Like most things in engineering, there is no right answer, and there are compromises all the way. You just have to weigh up the pros and cons and make a decision. Of course, reasonable people may disagree on the weights, so some debate may be necessary.
>
> The pros and cons are clear here. I think it would be nice to have consistent syntax and keep Scott away, but it's just syntax. It doesn't affect the expressiveness, power, or performance of the language. The cost is that it breaks almost all working code. I do not think the pros outweigh the cons, so I do not think this should go ahead, and we will just have to live with Scott explaining why some attributes have @ and others do not.

And to add to that, this proposal doesn't even make things consistent. You _still_ have to explain why some attributes have @ and some don't. It's just that now two of them have @ whereas they didn't before. final, static, public, const, etc. all still don't have @, and they're all function attributes too. So, it doesn't increase consistency. It just moves it around. And then we have to explain why some older code or tutorials _don't_ have @ on pure or nothrow, making it so that we have _more_ to explain.

I appreciate the sentiment of wanting to clean things up and make them more consistent, but I really don't think this does that. If we want that, we'd either have to add @ to all attributes or remove it from all attributes. But then of course, we'd have stuff like @public and @static, which is inconsistent with other languages and would probably cause folks to complain about unnecessary inconsistencies with othe languages. So, I really don't think that we can avoid this problem. It's just a question of which form of it we want to deal with and how much code breakage we're willing to put up with to get it there.

- Jonathan M Davis

On Sat, Jun 21, 2014 at 12:41:26PM -0700, Jonathan M Davis via Digitalmars-d wrote: [...]
> And to add to that, this proposal doesn't even make things consistent. You _still_ have to explain why some attributes have @ and some don't. It's just that now two of them have @ whereas they didn't before. final, static, public, const, etc. all still don't have @, and they're all function attributes too.  So, it doesn't increase consistency. It just moves it around. And then we have to explain why some older code or tutorials _don't_ have @ on pure or nothrow, making it so that we have _more_ to explain.
> 
> I appreciate the sentiment of wanting to clean things up and make them more consistent, but I really don't think this does that. If we want that, we'd either have to add @ to all attributes or remove it from all attributes. But then of course, we'd have stuff like @public and @static, which is inconsistent with other languages and would probably cause folks to complain about unnecessary inconsistencies with othe languages. So, I really don't think that we can avoid this problem. It's just a question of which form of it we want to deal with and how much code breakage we're willing to put up with to get it there.
[...]

Maybe we should be considering *removing* @ from @safe and @nogc? But I don't see that flying either, since it can well conflict with existing user-defined identifiers.

OTOH, I think there is some distinction between, say, pure and public, because pure is something that can be inferred, and it involves restricting the set of allowed code in the body of the function (likewise with nothrow, @safe, @nogc), whereas public merely affects external access to the function. The latter can't be inferred automatically (and it doesn't make sense to do so), but the former can. Furthermore, in the former case, it makes sense for a function's attributes to depend on its arguments -- e.g., opApply can be pure if the delegate argument is pure, but it doesn't make sense for opApply to be public/protected/private just because its argument is.

So there's at least some amount of rationale for treating the two categories of attributes differently.


T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry

On Saturday, 21 June 2014 at 19:41:42 UTC, Jonathan M Davis via Digitalmars-d wrote:
> And to add to that, this proposal doesn't even make things consistent. You
> _still_ have to explain why some attributes have @ and some don't. It's just
> that now two of them have @ whereas they didn't before. final, static, public,
> const, etc. all still don't have @, and they're all function attributes too.

I think the proposal said that the type constructors would be exempt, You wouldn't have @const but you would have @final.

> So, it doesn't increase consistency. It just moves it around. And then we have
> to explain why some older code or tutorials _don't_ have @ on pure or nothrow,
> making it so that we have _more_ to explain.

We can either say "It used to be inconsistent, but then we did nothing", or "It used to be inconsistent, but then we fixed it. Run this tool on your code and you'll be fine."

> I appreciate the sentiment of wanting to clean things up and make them more
> consistent, but I really don't think this does that. If we want that, we'd
> either have to add @ to all attributes or remove it from all attributes. But
> then of course, we'd have stuff like @public and @static, which is
> inconsistent with other languages and would probably cause folks to complain
> about unnecessary inconsistencies with othe languages. So, I really don't
> think that we can avoid this problem. It's just a question of which form of it
> we want to deal with and how much code breakage we're willing to put up with
> to get it there.

Why is D being consistent with other languages a more important goal than D being consistent with D?