Re: @safe(bool)

[12345swordy via Digitalmars-d]

On Saturday, 26 August 2017 at 02:19:53 UTC, bitwise wrote:

On Saturday, 26 August 2017 at 01:13:56 UTC, 12345swordy wrote:

On Friday, 25 August 2017 at 18:18:14 UTC, bitwise wrote:
On Thursday, 24 August 2017 at 14:59:05 UTC, 12345swordy 
wrote:

[...]

How about actually answering the question instead of 
assuming that I can't look up the definition of any words?


While your statement may sound nice to you, and to some 
others in this thread, that does not make it well-founded.
It's not a statement it's a question. Stop beating around the 
bush and just answer it already.


Ok..gonna have to assume your just trolling at this point.
Then you don't mind me dismissing your position as you fail to 
provide specific examples that I requested.

Re: @safe(bool)

[bitwise via Digitalmars-d]

On Saturday, 26 August 2017 at 01:13:56 UTC, 12345swordy wrote:

On Friday, 25 August 2017 at 18:18:14 UTC, bitwise wrote:

On Thursday, 24 August 2017 at 14:59:05 UTC, 12345swordy wrote:

[...]

How about actually answering the question instead of assuming 
that I can't look up the definition of any words?


While your statement may sound nice to you, and to some others 
in this thread, that does not make it well-founded.
It's not a statement it's a question. Stop beating around the 
bush and just answer it already.


Ok..gonna have to assume your just trolling at this point.

Re: @safe(bool)

[12345swordy via Digitalmars-d]

On Friday, 25 August 2017 at 18:18:14 UTC, bitwise wrote:

On Thursday, 24 August 2017 at 14:59:05 UTC, 12345swordy wrote:

[...]

How about actually answering the question instead of assuming 
that I can't look up the definition of any words?


While your statement may sound nice to you, and to some others 
in this thread, that does not make it well-founded.
It's not a statement it's a question. Stop beating around the 
bush and just answer it already.

Re: @safe(bool)

[bitwise via Digitalmars-d]

On Thursday, 24 August 2017 at 14:59:05 UTC, 12345swordy wrote:

[...]

How about actually answering the question instead of assuming 
that I can't look up the definition of any words?


While your statement may sound nice to you, and to some others in 
this thread, that does not make it well-founded. What you said 
was nothing more than a statement of opinion that's as uselessly 
generic as "premature optimization is the root of all evil".


If you look back at my posts, you can see several instances of me 
citing personal experience (using extension methods in C#) or 
trying to relate the situation to existing features (function 
overloading). If you have evidence or experience that directly 
contradicts my arguments, I'm all ears, but a statement of 
opinion alone is not helpful.

Re: @safe(bool)

[12345swordy via Digitalmars-d]

On Thursday, 24 August 2017 at 01:38:50 UTC, bitwise wrote:

On Wednesday, 23 August 2017 at 13:28:37 UTC, 12345swordy wrote:

On Wednesday, 23 August 2017 at 02:24:51 UTC, bitwise wrote:

[...]

Platitudes cause poor language design, not the completely 
reasonable expectation of good tools.


And who is "Platitude" here specifically?


http://lmgtfy.com/?q=platitude ;)


How about actually answering the question instead of assuming 
that I can't look up the definition of any words?

Re: @safe(bool)

[bitwise via Digitalmars-d]

On Wednesday, 23 August 2017 at 13:28:37 UTC, 12345swordy wrote:

On Wednesday, 23 August 2017 at 02:24:51 UTC, bitwise wrote:

[...]

Platitudes cause poor language design, not the completely 
reasonable expectation of good tools.


And who is "Platitude" here specifically?


http://lmgtfy.com/?q=platitude ;)

Re: @safe(bool)

[12345swordy via Digitalmars-d]

On Wednesday, 23 August 2017 at 02:24:51 UTC, bitwise wrote:

On Tuesday, 22 August 2017 at 19:46:00 UTC, 12345swordy wrote:

On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote:
On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis 
wrote:

[...]

[...]


There was a time that people would write code with even 
modest performance requirements in assembler for fear of what 
the compiler would spit out, but that's in the past, as is 
the notion of trying to develop without an IDE.


You shouldn't rely on an IDE to compensate poor language 
design. That is coming from a guy who prefers IDE's.


Platitudes cause poor language design, not the completely 
reasonable expectation of good tools.


And who is "Platitude" here specifically?

Re: @safe(bool)

[bitwise via Digitalmars-d]

On Tuesday, 22 August 2017 at 19:56:46 UTC, Timon Gehr wrote:

On 22.08.2017 21:46, 12345swordy wrote:

On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote:
On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis 
wrote:

[...]
If you need an IDE to figure out what your code is doing, 
that's an epic fail IMHO. Walter has made similar statements 
on several occasions.


There was a time that people would write code with even 
modest performance requirements in assembler for fear of what 
the compiler would spit out, but that's in the past, as is 
the notion of trying to develop without an IDE.


You shouldn't rely on an IDE to compensate poor language 
design. That is coming from a guy who prefers IDE's.


I disagree with both the notion that this is poor language 
design and that an IDE is required to make sense out of code 
that uses the new feature.


"Required" is a bit of a strong word here. In the absence of good 
practice, any language feature can be abused to make code 
confusing.


Function overloading is a good example of a feature that is 
usable as is, but made much better with a good IDE. But the same 
way I wouldn't name every function in a class "performAction" and 
pass a 50 member enum to it to tell it what to actually do, I 
wouldn't have more than 4-5 different types of function attribute 
combinations, and if I did, I wouldn't spread them out among 10 
different files. What little extra effort it takes to look up the 
attributes of a function in an atmosphere of good practice can 
easily be made up for with good tools, and no one _has_ to use 
bundled up attributes.

Re: @safe(bool)

[bitwise via Digitalmars-d]

On Tuesday, 22 August 2017 at 19:46:00 UTC, 12345swordy wrote:

On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote:
On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis 
wrote:

[...]
If you need an IDE to figure out what your code is doing, 
that's an epic fail IMHO. Walter has made similar statements 
on several occasions.


There was a time that people would write code with even modest 
performance requirements in assembler for fear of what the 
compiler would spit out, but that's in the past, as is the 
notion of trying to develop without an IDE.


You shouldn't rely on an IDE to compensate poor language 
design. That is coming from a guy who prefers IDE's.


Platitudes cause poor language design, not the completely 
reasonable expectation of good tools.

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Tuesday, 22 August 2017 at 19:56:46 UTC, Timon Gehr wrote:
I disagree with both the notion that this is poor language 
design and that an IDE is required to make sense out of code 
that uses the new feature.


Indeed, I can't imagine a DIP suggesting to make core regular 
attributes, keyword like getting very far had those attributes 
been added after we got UDAs.


While IDEs may be able to show you instantly what attributes a 
function has, so would the compiler (in the form of an errors 
message if you got it wrong, quality of said message 
notwithstanding), documentation, any dcd based tooling (or any 
other tools that can do symbol resolution) and code searches.


If the tooling is insufficient for this use case, then it should 
be improved as this is a problem that is able to be solved 
completely by tooling. If you choose not to use the tooling, and 
it would solve this problem, then that is fine, but I don't think 
we should limit the design of the language because of that.

Re: @safe(bool)

[Timon Gehr via Digitalmars-d]

On 22.08.2017 21:46, 12345swordy wrote:

On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote:

On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote:
[...]
If you need an IDE to figure out what your code is doing, that's an 
epic fail IMHO. Walter has made similar statements on several occasions.


There was a time that people would write code with even modest 
performance requirements in assembler for fear of what the compiler 
would spit out, but that's in the past, as is the notion of trying to 
develop without an IDE.


You shouldn't rely on an IDE to compensate poor language design. That is 
coming from a guy who prefers IDE's.


I disagree with both the notion that this is poor language design and 
that an IDE is required to make sense out of code that uses the new feature.

Re: @safe(bool)

[12345swordy via Digitalmars-d]

On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote:
On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis 
wrote:

[...]
If you need an IDE to figure out what your code is doing, 
that's an epic fail IMHO. Walter has made similar statements 
on several occasions.


There was a time that people would write code with even modest 
performance requirements in assembler for fear of what the 
compiler would spit out, but that's in the past, as is the 
notion of trying to develop without an IDE.


You shouldn't rely on an IDE to compensate poor language design. 
That is coming from a guy who prefers IDE's.

Re: @safe(bool)

[bitwise via Digitalmars-d]

On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis 
wrote:

[...]
If you need an IDE to figure out what your code is doing, 
that's an epic fail IMHO. Walter has made similar statements on 
several occasions.


There was a time that people would write code with even modest 
performance requirements in assembler for fear of what the 
compiler would spit out, but that's in the past, as is the notion 
of trying to develop without an IDE.

Re: @safe(bool)

[Jonathan M Davis via Digitalmars-d]

On Tuesday, August 22, 2017 09:11:13 Steven Schveighoffer via Digitalmars-d 
wrote:
> On 8/21/17 9:20 PM, Jonathan M Davis via Digitalmars-d wrote:
> > Regardless, it means that I would need to run a tool to figure out which
> > attributes actually applied to a function rather than just reading it
> > like I could do now. And the fact that this is can be done with UDAs
> > right now is _not_ a plus. I can understand wanting to reduce the
> > number of attributes being manually applied to functions, but I think
> > that hiding them with aliases and/or combined attributes is a
> > maintenance nightmare and would argue that it's just plain bad
> > practice.
>
> Not for or against the DIP, but this is already the case, due to block
> attributes. I have to search around the file to find out whether pure:
> is at the top, etc. In fact, I've made recommendations many times on PRs
> to add an attribute to a function, to find out it's already handled at
> the top.
>
> I would think documentation generation should solve the issues.

Honestly, I tend to be against block attributes for this very reason, but at
least with block attributes, you can grep/search the file and find the
information. With this DIP, you potentially have to go looking in other
libraries to figure out which attributes actually apply, and you have to
track down every attribute on a function just to figure out whether a
built-in attribute applies to it. And I bet the documentation generation (at
least as it stands) would just put the custom attributes on there and not
translate them to their constituent attributes. But even if it put all of
the attributes on there individually, honestly, I think that it's a huge
negative if I have to run the documentation generation to figure out what
some code is doing. IMHO, I should be able to read the code and see what
it's doing without running extra tools or searching through several other
projects. Sometimes (particularly with more complicated code where you have
to understand other functionality to understand the stuff in front of you),
life doesn't work that way, but that should be the goal. And aliasing and
combining attributes goes completely against that goal. Stuff like block
attributes already harm it, but at least they're localized.

- Jonathan M Davis

Re: @safe(bool)

[Steven Schveighoffer via Digitalmars-d]

On 8/21/17 9:20 PM, Jonathan M Davis via Digitalmars-d wrote:

Regardless, it means that I would need to run a tool to figure out which
attributes actually applied to a function rather than just reading it like I
could do now. And the fact that this is can be done with UDAs right now is
_not_ a plus. I can understand wanting to reduce the number of attributes
being manually applied to functions, but I think that hiding them with
aliases and/or combined attributes is a maintenance nightmare and would
argue that it's just plain bad practice.


Not for or against the DIP, but this is already the case, due to block 
attributes. I have to search around the file to find out whether pure: 
is at the top, etc. In fact, I've made recommendations many times on PRs 
to add an attribute to a function, to find out it's already handled at 
the top.


I would think documentation generation should solve the issues.

-Steve

Re: @safe(bool)

[Marco Leise via Digitalmars-d]

Am Sun, 20 Aug 2017 00:29:11 +
schrieb Nicholas Wilson :

> On Saturday, 19 August 2017 at 17:10:54 UTC, bitwise wrote:
> > I'm still concerned about having to read code that's laced full 
> > of custom attributes, the resolution of which may span several 
> > files, templates, etc.
> >
> > I also think this type of thing could have a detrimental effect 
> > on modularity when you end up having to include "myAttribs.d" 
> > in every single file you want to work on. I would much rather 
> > have a flexible in-language solution, or a solution that didn't 
> > require me to define my own attributes.  
> 
> Having worked on a project with a lot of attributes, my 
> suggestion would be to import it via a package.d, you'll be 
> importing that anyway.

+1
A bigger project /usually/ has some default imports. Typical
use cases are unifying compiler versions and architectures,
back-porting new Phobos features and custom error handling and
logging.
For example, in dub the modules in the "internal" package are
imported into most of the bigger modules.
You can also create a file template with documentation header,
license and default imports if you need to create a lot of
modules.

-- 
Marco

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Tuesday, 22 August 2017 at 01:20:13 UTC, Jonathan M Davis 
wrote:
On Tuesday, August 22, 2017 01:01:15 Nicholas Wilson via 
Digitalmars-d wrote:
That attributes are combinable and aliasable are nice side 
effects of being regular attributes which in general are one 
of the main foci of the DIP (the other being fixing the 
non-invertibility).


Which is precisely why I don't like it. Fixing 
non-invertibility is great. I don't like any of the rest.


Any editor that has dcd (or other tooling) support should be 
able to immediately resolve which aliases refer to what as its 
only symbol resolution. Yes it won't be able to do inference 
but it can't under the current system either.


Regardless, it means that I would need to run a tool to figure 
out which attributes actually applied to a function rather than 
just reading it like I could do now. And the fact that this is 
can be done with UDAs right now is _not_ a plus. I can 
understand wanting to reduce the number of attributes being 
manually applied to functions, but I think that hiding them 
with aliases and/or combined attributes is a maintenance 
nightmare and would argue that it's just plain bad practice.


- Jonathan M Davis


Then we shall just have to agree to disagree. I am of the opinion 
that they are very useful properties of UDAs and that's part of 
why I wrote that DIP.

Re: @safe(bool)

[Jonathan M Davis via Digitalmars-d]

On Tuesday, August 22, 2017 01:01:15 Nicholas Wilson via Digitalmars-d 
wrote:
> On Monday, 21 August 2017 at 08:09:25 UTC, Jonathan M Davis wrote:
> > Except that someone could then be pulling in attributes from
> > 3rd party libraries and using those, meaning that you'll
> > potentially have to go digging through other libraries just to
> > figure out whether a function is being marked with @safe or
> > not. You get some of that pain with any custom attribute, but
> > currently, the built-in attributes avoid it completely, and
> > being able to combine attributes makes it far worse, since then
> > you potentially have to go searching through a chain of
> > declarations to figure out which attributes are actually being
> > used. I can understand folks wanting to reduce how many
> > attributes they have to manually put on functions, but I think
> > that it risks being a maintenance nightmare to have to deal
> > with combined or aliased attributes. I would _much_ rather see
> > each attribute applied individually, because it's far easier to
> > figure out what's going on that way. We already have enough
> > problems figuring out which attributes are in play when dealing
> > with attribute inference. I _really_ don't want to see aliasing
> > and combining added to the mix - especially with the built-in
> > attributes. And that seems to be one of if not the main
> > motivation of the DIP.
> >
> > - Jonathan M Davis
>
> That attributes are combinable and aliasable are nice side
> effects of being regular attributes which in general are one of
> the main foci of the DIP (the other being fixing the
> non-invertibility).

Which is precisely why I don't like it. Fixing non-invertibility is great. I
don't like any of the rest.

> Any editor that has dcd (or other tooling) support should be able
> to immediately resolve which aliases refer to what as its only
> symbol resolution. Yes it won't be able to do inference but it
> can't under the current system either.

Regardless, it means that I would need to run a tool to figure out which
attributes actually applied to a function rather than just reading it like I
could do now. And the fact that this is can be done with UDAs right now is
_not_ a plus. I can understand wanting to reduce the number of attributes
being manually applied to functions, but I think that hiding them with
aliases and/or combined attributes is a maintenance nightmare and would
argue that it's just plain bad practice.

- Jonathan M Davis

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Monday, 21 August 2017 at 08:09:25 UTC, Jonathan M Davis wrote:
Except that someone could then be pulling in attributes from 
3rd party libraries and using those, meaning that you'll 
potentially have to go digging through other libraries just to 
figure out whether a function is being marked with @safe or 
not. You get some of that pain with any custom attribute, but 
currently, the built-in attributes avoid it completely, and 
being able to combine attributes makes it far worse, since then 
you potentially have to go searching through a chain of 
declarations to figure out which attributes are actually being 
used. I can understand folks wanting to reduce how many 
attributes they have to manually put on functions, but I think 
that it risks being a maintenance nightmare to have to deal 
with combined or aliased attributes. I would _much_ rather see 
each attribute applied individually, because it's far easier to 
figure out what's going on that way. We already have enough 
problems figuring out which attributes are in play when dealing 
with attribute inference. I _really_ don't want to see aliasing 
and combining added to the mix - especially with the built-in 
attributes. And that seems to be one of if not the main 
motivation of the DIP.


- Jonathan M Davis


That attributes are combinable and aliasable are nice side 
effects of being regular attributes which in general are one of 
the main foci of the DIP (the other being fixing the 
non-invertibility).


Any editor that has dcd (or other tooling) support should be able 
to immediately resolve which aliases refer to what as its only 
symbol resolution. Yes it won't be able to do inference but it 
can't under the current system either.

Re: @safe(bool)

[Jonathan M Davis via Digitalmars-d]

On Tuesday, August 22, 2017 00:21:16 bitwise via Digitalmars-d wrote:
> On Monday, 21 August 2017 at 08:09:25 UTC, Jonathan M Davis wrote:
> > you potentially have to go searching through a chain of
> > declarations to figure out which attributes are actually being
> > used.
>
> A good IDE should give you this info if you hover over a
> function. I realize D's tool support is spotty at the moment, but
> it seems like the kind of think that's ok to be optimistic about.

If you need an IDE to figure out what your code is doing, that's an epic
fail IMHO. Walter has made similar statements on several occasions. D was
originally designed in such a way that IDEs should not be necessary (e.g. it
tries to avoid a lot of the boilerplate code that is typical in Java
programs). Most of the folks around here do not use IDEs. I use (g)vim as my
code editor, and I have no desire to use an IDE. I should be able to figure
out what's going on just by looking at the code, and having to go spelunking
to figure out which attributes really apply because they're hidden behind
aliases or combined in other attributes is just wasting my time IMHO. As
long as the attributes are applied directly without being renamed (be it
directly on the function or to the module as a whole), then the situation is
quite tractable, but if we end up with aliased attributes and combined
attributes, that goes completely out the window.

- Jonathan M Davis

Re: @safe(bool)

[bitwise via Digitalmars-d]

On Monday, 21 August 2017 at 08:09:25 UTC, Jonathan M Davis wrote:


you potentially have to go searching through a chain of 
declarations to figure out which attributes are actually being 
used.


A good IDE should give you this info if you hover over a 
function. I realize D's tool support is spotty at the moment, but 
it seems like the kind of think that's ok to be optimistic about.

Re: @safe(bool)

[Jonathan M Davis via Digitalmars-d]

On Monday, August 21, 2017 10:41:49 Danni Coy via Digitalmars-d wrote:
> > For instance, as it stands, it's relatively easy to figure out whether
> > @safe
> > has been explicitly applied. You can look on the function and look for
> > @safe: or @safe {} which affects it. The same goes for other attributes.
> > But
> > as soon as you can do stuff like create new attributes that combine
> > attributes, you lose that completely. Suddenly. you have to worry about
> > whatever attributes someone came up on their own for their project which
> > apply @safe or final or @nogc or whatever. You can no longer search or
> > grep for an attribute like @safe to see whether it applies.
>
> you can still search or grep but it's now a two step process. when you
> grep the @safe attribute you will find the custom attribute declaration.
> you then search for the custom declaration. You need to do the first step
> exactly once for each codebase (unless you forget).
>
> It's more diffucult but only a little bit.

Except that someone could then be pulling in attributes from 3rd party
libraries and using those, meaning that you'll potentially have to go
digging through other libraries just to figure out whether a function is
being marked with @safe or not. You get some of that pain with any custom
attribute, but currently, the built-in attributes avoid it completely, and
being able to combine attributes makes it far worse, since then you
potentially have to go searching through a chain of declarations to figure
out which attributes are actually being used. I can understand folks wanting
to reduce how many attributes they have to manually put on functions, but I
think that it risks being a maintenance nightmare to have to deal with
combined or aliased attributes. I would _much_ rather see each attribute
applied individually, because it's far easier to figure out what's going on
that way. We already have enough problems figuring out which attributes are
in play when dealing with attribute inference. I _really_ don't want to see
aliasing and combining added to the mix - especially with the built-in
attributes. And that seems to be one of if not the main motivation of the
DIP.

- Jonathan M Davis

Re: @safe(bool)

[Danni Coy via Digitalmars-d]

> For instance, as it stands, it's relatively easy to figure out whether
> @safe
> has been explicitly applied. You can look on the function and look for
> @safe: or @safe {} which affects it. The same goes for other attributes.
> But
> as soon as you can do stuff like create new attributes that combine
> attributes, you lose that completely. Suddenly. you have to worry about
> whatever attributes someone came up on their own for their project which
> apply @safe or final or @nogc or whatever. You can no longer search or grep
> for an attribute like @safe to see whether it applies.
>
>
you can still search or grep but it's now a two step process. when you grep
the @safe attribute you will find the custom attribute declaration.
you then search for the custom declaration. You need to do the first step
exactly once for each codebase (unless you forget).

It's more diffucult but only a little bit.

Re: @safe(bool)

[bitwise via Digitalmars-d]

On Sunday, 20 August 2017 at 01:33:00 UTC, Nicholas Wilson wrote:


 I'm not quite sure how this would lead to a loss of modularity?


Not sure if modularity is exactly the right word. The problem 
would be akin to extension methods in C#, or even a useful set of 
UFC's in D.


So, imagine you decide you need DateTime.LastWeek() or something 
similar. This turns out to be something you end up needing in 
most of your projects. So first of all, you're now required to 
start bringing this file into every project you work on. This is 
already annoying. Then, one day, you decide you also need 
DateTime.FortnightAgo(). So you add it to the file, except that 
all the other versions are now out of sync. You think, maybe I 
should have made a repository!? First of all, too late. Second, 
you now have to clone a repo into all your new projects instead 
of dragging and dropping a file, and update the repo every time 
you want to work on the project in case anything changed. At this 
point, any reasonable person would be frustratedbut 
wait...you also need some extensions for Math as well, which are 
not necessarily related to the extensions for DateTime. I suppose 
you could start throwing together your own small support library 
with all of these things in there... But wait...some of the 
extensions are platform specific *facepalm*. So eventually, you 
end up with a chart like this[1] describing which of these libs 
are in each of your projects.



The catch is, that a lot of the time, the things you make are 
these extensions for are so ubiquitous that they should probably 
just be included in the language, or standard library. An easy 
example is the million different variations of C++ "thread", 
"mutex" and "hashtable" that were built while the C++ community 
took a coffee break from 1998 to 2011 ;)


I think I've painted the picture sufficiently at this point.

[1] http://i.imgur.com/cQxxQJs.png

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Sunday, 20 August 2017 at 02:53:14 UTC, jmh530 wrote:
On Sunday, 20 August 2017 at 00:55:41 UTC, Nicholas Wilson 
wrote:


Sorry, I was referring to preconfigurations in druntime like
https://github.com/dlang/DIPs/pull/89/files#diff-26bf588c0174e6cd0fe3d4af615bebdaL60


So modifying core.attribute.defaultAttributeSet in the runtime 
is the only way to change the default attribute set,


Yes, whether that be a custom runtime or through version 
conditions that define core.attribute.defaultAttributeSet.



but one
could create a custom attribute that they just use as needed. 
So one could just look at the top of the file to see if the 
code has something like @myDefaultAttributeSet.


Yes. Hopefully a bit more descriptive though ;)

Re: @safe(bool)

[jmh530 via Digitalmars-d]

On Sunday, 20 August 2017 at 00:55:41 UTC, Nicholas Wilson wrote:


Sorry, I was referring to preconfigurations in druntime like
https://github.com/dlang/DIPs/pull/89/files#diff-26bf588c0174e6cd0fe3d4af615bebdaL60


So modifying core.attribute.defaultAttributeSet in the runtime is 
the only way to change the default attribute set, but one could 
create a custom attribute that they just use as needed. So one 
could just look at the top of the file to see if the code has 
something like @myDefaultAttributeSet.

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Sunday, 20 August 2017 at 01:05:39 UTC, bitwise wrote:
This is indeed, a nice solution. I am a _bit_ worried about 
abuse, and loss of modularity, but aside from that, I think 
it's a better solution overall.


All features in the style of "I know what I'm doing, just let me 
do it!" (=void, @trusted ect.) are open to abuse but I don't 
think we've ever had problems with them. They tend to be used 
sparingly and only when absolutely necessary.


 I'm not quite sure how this would lead to a loss of modularity?


The only downside is that the second form leaves itself open to


Easily fixed with a template constraint, right?


True, too early in the morning. zzz.

This could potentially render a large portion of the projects 
on code.dlang.org broken though. What would be nice, is if 
code.dlang.org regularly built all the projects, and notified 
the authors of the breakage, possibly sending a list of recent 
compiler changes as well.


I don' think It would break too much, but we have @future to 
mitigate all potential breakages from this DIP. Autotesting is 
obviously desirable.

Re: @safe(bool)

[bitwise via Digitalmars-d]

On Sunday, 20 August 2017 at 00:49:28 UTC, Nicholas Wilson wrote:


[...]

With DIP 1012 you should be able to go

 struct Container(T, bool safetyOn = true)
 {
static if(safe)
RefCounted!(T[]) data;
else
T[] data;

auto opSlice() @safeIf!safetyOn {
return Range(data, 0, data.length);
}
 }

 template safeIf(bool cond)
 {
 static if (cond) alias safeIf = AliasSeq!(safe);
 else   alias safeIf = AliasSeq!();
 }

or even just

 struct Container(T, FunctionSafety safetyOn = safe)
 {
static if(safe)
RefCounted!(T[]) data;
else
T[] data;

auto opSlice() @safetyOn {
return Range(data, 0, data.length);
}
 }

Container!int foo; // Container!(int, safe)
Container!(int, system) bar;


This is indeed, a nice solution. I am a _bit_ worried about 
abuse, and loss of modularity, but aside from that, I think it's 
a better solution overall.



The only downside is that the second form leaves itself open to


Easily fixed with a template constraint, right?


This could potentially render a large portion of the projects on 
code.dlang.org broken though. What would be nice, is if 
code.dlang.org regularly built all the projects, and notified the 
authors of the breakage, possibly sending a list of recent 
compiler changes as well.

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Saturday, 19 August 2017 at 20:39:07 UTC, jmh530 wrote:
On Saturday, 19 August 2017 at 13:09:41 UTC, Nicholas Wilson 
wrote:


Hacking the runtime is certainly one way to achieve changing 
the default attributes.
However having them as regular attributes means that is is 
possible to do configuration by version statements, which is 
a) much easier than hacking the runtime and b) causes much 
less fragmentation.




This may not be so elegant...but what if one could only take an 
alias of these in core.attributes or in a package.d file? At 
least that way people would know where to look if widespread 
changes are made?


Sorry, I was referring to preconfigurations in druntime like
https://github.com/dlang/DIPs/pull/89/files#diff-26bf588c0174e6cd0fe3d4af615bebdaL60

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Saturday, 19 August 2017 at 19:15:25 UTC, bitwise wrote:
On Saturday, 19 August 2017 at 18:22:58 UTC, Guillaume Boucher 
wrote:

On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:
In a high-performance context though, the performance hit may 
be unacceptable.


Well in those super rare situations, there's always the 
workaround with mixins:


Those situations are not rare.

mixin template funcWithAttr(string decl, string attributes, 
string code) {

pragma(msg, "<<<" ~ code ~ ">>>");
mixin(decl ~ attributes ~ "{" ~ code ~" }");
}

struct Container(T, bool safetyOn = true)
{
static if(safe)
RefCounted!(T[]) data;
else
T[] data;

	mixin funcWithAttr!("auto opSlice()", safetyOn ? "@safe" : 
"", q{

return Range(data, 0, data.length);
});
}


Really?


With DIP 1012 you should be able to go

 struct Container(T, bool safetyOn = true)
 {
static if(safe)
RefCounted!(T[]) data;
else
T[] data;

auto opSlice() @safeIf!safetyOn {
return Range(data, 0, data.length);
}
 }

 template safeIf(bool cond)
 {
 static if (cond) alias safeIf = AliasSeq!(safe);
 else   alias safeIf = AliasSeq!();
 }

or even just

 struct Container(T, FunctionSafety safetyOn = safe)
 {
static if(safe)
RefCounted!(T[]) data;
else
T[] data;

auto opSlice() @safetyOn {
return Range(data, 0, data.length);
}
 }

Container!int foo; // Container!(int, safe)
Container!(int, system) bar;

The only downside is that the second form leaves itself open to
Container!(int, trusted) quux;
which is probably undesirable.

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Saturday, 19 August 2017 at 17:10:54 UTC, bitwise wrote:
I'm still concerned about having to read code that's laced full 
of custom attributes, the resolution of which may span several 
files, templates, etc.


I also think this type of thing could have a detrimental effect 
on modularity when you end up having to include "myAttribs.d" 
in every single file you want to work on. I would much rather 
have a flexible in-language solution, or a solution that didn't 
require me to define my own attributes.


Having worked on a project with a lot of attributes, my 
suggestion would be to import it via a package.d, you'll be 
importing that anyway.

Re: @safe(bool)

[jmh530 via Digitalmars-d]

On Saturday, 19 August 2017 at 13:09:41 UTC, Nicholas Wilson 
wrote:


Hacking the runtime is certainly one way to achieve changing 
the default attributes.
However having them as regular attributes means that is is 
possible to do configuration by version statements, which is a) 
much easier than hacking the runtime and b) causes much less 
fragmentation.




This may not be so elegant...but what if one could only take an 
alias of these in core.attributes or in a package.d file? At 
least that way people would know where to look if widespread 
changes are made?

Re: @safe(bool)

[bitwise via Digitalmars-d]

On Saturday, 19 August 2017 at 18:22:58 UTC, Guillaume Boucher 
wrote:

On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:
In a high-performance context though, the performance hit may 
be unacceptable.


Well in those super rare situations, there's always the 
workaround with mixins:


Those situations are not rare.

mixin template funcWithAttr(string decl, string attributes, 
string code) {

pragma(msg, "<<<" ~ code ~ ">>>");
mixin(decl ~ attributes ~ "{" ~ code ~" }");
}

struct Container(T, bool safetyOn = true)
{
static if(safe)
RefCounted!(T[]) data;
else
T[] data;

	mixin funcWithAttr!("auto opSlice()", safetyOn ? "@safe" : "", 
q{

return Range(data, 0, data.length);
});
}


Really?

Re: @safe(bool)

[Guillaume Boucher via Digitalmars-d]

On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:
In a high-performance context though, the performance hit may 
be unacceptable.


Well in those super rare situations, there's always the 
workaround with mixins:


mixin template funcWithAttr(string decl, string attributes, 
string code) {

pragma(msg, "<<<" ~ code ~ ">>>");
mixin(decl ~ attributes ~ "{" ~ code ~" }");
}

struct Container(T, bool safetyOn = true)
{
static if(safe)
RefCounted!(T[]) data;
else
T[] data;

mixin funcWithAttr!("auto opSlice()", safetyOn ? "@safe" : "", q{
return Range(data, 0, data.length);
});
}

Re: @safe(bool)

[Guillaume Boucher via Digitalmars-d]

On Saturday, 19 August 2017 at 16:02:27 UTC, bitwise wrote:

We have to consider the potential for abuse.


I don't like measuring features on the potential for abuse, but 
this feature cries for abuse.  Even in the simpler form of your 
proposal.


Let's say there are two functions with conditional @safe

f(T)(...) @safe(!hasAliasing!T) {...}
g(bool B)(...) @safe(B) {...}

and we combine them into another function,

h(T,bool B) @safe(!hasAliasing!T && B) {
  f(T)(...);
  g(B)(...);
}

then in the correct @safe specification there is an additional 
clause for every conditionally-safe function.


This doesn't scale well.

So the guideline would be to use your feature very rarely and 
only if it's obvious from the meaning of the template arguments; 
if it gets too complicated, just don't specify it.


Which would mean the feature should only be used in few corner 
cases, and is thus not worth the cost of complicating the 
language.



You already commented on the other usage of dip 1012, the @nice 
and @naughty attributes.  They just don't scale in a similar way.



C++ has had the same feature for some time: noexcept(true) means 
noexcept, noexcept(false) means an exception may be thrown (of 
course this works with any constant expressions).
I just grepped through Boost and I have found 53 uses of 
noexcept(expression), from 5264 total uses of noexcept (excluding 
the math library). And Boost is one of those libraries that are 
overly precise with such things to a degree that the code becomes 
unreadable.  In code outside of Boost and the standard library, 
noexcept(expression) it is basically unused.

Re: @safe(bool)

[bitwise via Digitalmars-d]

On Friday, 18 August 2017 at 23:48:05 UTC, Nicholas Wilson wrote:


The only breaking changes are nothrow and pure get a leading 
'@'.
They will go through a proper deprecation process and I will be 
very surprised if anything breaks. The new symbols added to 
core.attributes can use `@future` if need be to further reduce 
the likelihood of any breaking changes.


While the difference in attribute style(@, or no @) isn't that 
hard to deal with in practice, I am definitely in favor of a more 
consistent scheme. The current inconsistency looks bad, and IMO, 
that's a big deal. It makes D look tacky, and easy to dismiss.



How would you know what attributes were in effect before?


It wouldn't matter if your intention was to clobber them anyways 
with @default. And if you only wanted to clobber @nogc, you could 
use @nogc(false), and it still wouldn't matter what the inferred 
attribute set was.



I'm still concerned about having to read code that's laced full 
of custom attributes, the resolution of which may span several 
files, templates, etc.


I also think this type of thing could have a detrimental effect 
on modularity when you end up having to include "myAttribs.d" in 
every single file you want to work on. I would much rather have a 
flexible in-language solution, or a solution that didn't require 
me to define my own attributes.

Re: @safe(bool)

[bitwise via Digitalmars-d]

On Friday, 18 August 2017 at 18:15:33 UTC, Timon Gehr wrote:

[...]

alias naughty = AliasSeq!(impure,system,throws,gc);
alias nice = AliasSeq!(pure,safe,nothrow,nogc);

@nice void foo();
@naughty void bar();


We have to consider the potential for abuse.

For example, D's templates are great - but it doesn't mean that 
if you're making a math library, that you should template your 
matrix class on it's dimensions, just to fill it with static if's 
because half of the functionality only applies to a single 
dimension. Especially when you typically need 2-3 different 
versions at most(mat2, mat3, mat4). People do it though.


If things did turn out to be as simple as the example you posted, 
then I could see it being a useful way to hide some of D's 
painful attribute bloat, but I've got a feeling we'd start seeing 
things like "nice", "nicer", "nicest", 
"niceInDebugModeButNotReleaseModeUnlessAssertsAreEnabled", 
etc.

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Saturday, 19 August 2017 at 02:00:47 UTC, jmh530 wrote:
On Saturday, 19 August 2017 at 00:37:06 UTC, Nicholas Wilson 
wrote:


Having to change the default attributes will be a rare 
occurrence (embedded (nothrow, nogc final) security critical 
(safe).




My reading of that updated DIP is that you can only change the 
default attributes by hacking on DRuntime.


Hacking the runtime is certainly one way to achieve changing the 
default attributes.
However having them as regular attributes means that is is 
possible to do configuration by version statements, which is a) 
much easier than hacking the runtime and b) causes much less 
fragmentation.


I don't think we want to encourage people to change the default 
attributes, but I think its one of those features that we have in 
D for those who know what they're doing (e.g =void) and don't 
want to get in their way of doing so.


If a project has a custom runtime, I would figure most people 
would mention it somewhere.


I would hope so!

Re: @safe(bool)

[Manu via Digitalmars-d]

On 18 August 2017 at 02:32, bitwise via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> This came to mind while working on a set of containers.
>
> @safety often comes with a performance cost. For example, any container
> that wants to give out a range or iterator has to have a ref-counted or GC
> allocted payload to ensure safety. In a high-performance context though,
> the performance hit may be unacceptable.
>

This sounds like a job for `scope`.
Eg, given a container, the function that returns the range/iterator should
return a `scope` attributed range/iterator. This should insist that the
lifetime of the range that is returned be no longer than the container that
issued it.
We've needed scope to address these issues for a very long time, and it
finally arrived! I'm not sure how far it extends yet though, it's not well
documented yet, and I haven't seen it get a lot of action. I'm not sure
where the boundaries are.

Re: @safe(bool)

[jmh530 via Digitalmars-d]

On Saturday, 19 August 2017 at 00:37:06 UTC, Nicholas Wilson 
wrote:


Having to change the default attributes will be a rare 
occurrence (embedded (nothrow, nogc final) security critical 
(safe).




My reading of that updated DIP is that you can only change the 
default attributes by hacking on DRuntime. If a project has a 
custom runtime, I would figure most people would mention it 
somewhere.

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Friday, 18 August 2017 at 23:11:34 UTC, Jonathan M Davis wrote:
On Friday, August 18, 2017 03:08:07 Nicholas Wilson via 
Digitalmars-d wrote:
On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis 
wrote:

If you think that then I have clearly failed to express the DIP
at all.
It solves exactly that. I completely fail to see how it is a
detriment to anything.
The 'whole pile of other stuff' is reduced in further revisions
to the DIP.


IMHO, the problem that needs solving is that you can't negate 
attributes, making stuff like


final:

problematic. DIP 1012 goes way beyond that, and I don't think 
that that extra stuff is at all worth having, and I do think 
that it's detrimental. For instance, as it stands, it's 
relatively easy to figure out whether @safe has been explicitly 
applied. You can look on the function and look for @safe: or 
@safe {} which affects it. The same goes for other attributes. 
But as soon as you can do stuff like create new attributes that 
combine attributes, you lose that completely. Suddenly. you 
have to worry about whatever attributes someone came up on 
their own for their project which apply @safe or final or @nogc 
or whatever. You can no longer search or grep for an attribute 
like @safe to see whether it applies.


As I have said before that is a deliberate feature of the DIP and 
not an incidental side product. Many people have requested such a 
feature. It also allows the DIP to solve the export problem:


```d
 version(MyLib_Build)
 enum MyLibExport = dynamicExport;
 else
 enum MyLibExport = dynamicImport;

 // Exported when building the shared object,
 // imported when linking against the shared object.
 @MyLibExport void foo(int x) { ... }
  ```
I get that you dislike that feature: yes you lose the ability to 
see it directly. grep still works (it might take more searches) 
and so does the documentation.


Similarly, having it be possible to alter the default 
attributes globally is incredibly bad IMHO. Suddenly, whether 
your module compiles or not could depend on what settings 
someone used for the default attributes. That should not be 
controlled externally. It should be part of the module just 
like whether a function or variable is const or not is part of 
the module and not defined externally. IMHO, it makes no sense 
whatsoever to have something external control attributes any 
more than it makes sense to control the return types or 
constness of symbols externally. That should be part of the 
declarations/definitions of the symbols in question.


That is a separable feature of the DIP, i.e. the DIP still 
functions without it, and if it truly so incredibly bad more 
people will say so.


But, say you are developing for an embedded platform: you have no 
room for libunwind or exception table and can't use the gc. You 
see some library, libFoo, and you think "Aha! that does exactly 
what I need", then you think can I use it? is this library 
@nothrow @nogc?
You could consult the documentation, but that doesn't tell you 
because there are a bunch of templates that dont have explicit 
attributes. You could try altering the examples to be @nothrow 
@nogc, or you could try to build the whole library as @nothrow 
@nogc and get error messages closer to the site of use.

Yes it is niché, but it has its uses.


[...] , but I don't at all agree that the rest of
what DIP 1012 is trying to do is beneficial.


It fixes export, allows grouping and manipulation of lists of 
attributes


I honestly think that what DIP 1012 is trying to do beyond 
making it possible to negate attributes


Yes,


is going to make the language worse and code harder to maintain.


No.

Yes, it will enable some things that you can't do now, but for 
the most part, I don't think that those things should be 
enabled. I don't want to have to deal with folks complaining 
that my library doesn't work right, because they tried a 
different default for the attributes with it.


Then that library is not for them.

I don't want to have to worry about trying to get someone 
else's code to work because they assumed something about the 
default attributes that does not hold in my case.


Then the library is not for you.

Having to change the default attributes will be a rare occurrence 
(embedded (nothrow, nogc final) security critical (safe).


I don't want to have to track down every custom attribute that 
someone came up with just to see whether they actually apply 
attributes like @safe or nothrow, just so that I can see 
whether those attributes apply.


-vcg-ast, documentation. But really, how others do you go: I 
really need to know if that some function has a particular 
combination of attributes (serious)?



I should be able to look at a
module and see which attributes have been applied to the 
functions in that module without having to go searching 
elsewhere.


IMHO, what needs to be solved with the built-in attributes, is 
the ability to negate the ones that don't have 

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Friday, 18 August 2017 at 15:16:55 UTC, bitwise wrote:
On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis 
wrote:

[...]

- Jonathan M Davis


Makes sense to me.

The first question that comes to mind is if the extra 
generality provided by DIP 1012 is actually useful, let alone, 
worth breaking changes.


It fixes the non-inverability. They become regular attributes 
instead of keywords. This has the effect of separating their 
definition from their usage allowing you to manipulate them like 
normal attributes, see https://github.com/dlang/DIPs/pull/89/ for 
the most recent revision.


The only breaking changes are nothrow and pure get a leading '@'.
They will go through a proper deprecation process and I will be 
very surprised if anything breaks. The new symbols added to 
core.attributes can use `@future` if need be to further reduce 
the likelihood of any breaking changes.


The rationale section of the DIP only mentions negating 
attributes, which is easily accomplished with what I suggested. 
Unless that section is expanded with additional practical use 
cases, then it doesn't seem worth the trouble to me.


The DIP mentions tagging a module declaration with default 
attributes. If the whole purpose of the DIP is to allow for 
negating attributes, why would you even need this change, when 
the DIP would effectively make it ok to put "@nogc: @safe: 
@etc:" at the top of the file?


This is changed in pull #89.

My suggestion does not cover "inferred" as discussed in the 
DIP, but that could be achieved by letting something like 
"@default" reset all attributes for a given symbol.


How would you know what attributes were in effect before?

I'll concede that DIP1012 makes more logical sense than the 
current state of things, but it seems like something that would 
be best achieved during a transition to a subsequent language 
version.


It seems commonplace here, to discard suggestions based on 
their current viability, when it may be better to add them to a 
feature backlog that could be considered when talking about the 
possibility of a D3.


Why? Breakage will be completely contained with transitional 
behaviour, i.e. the compiler will treat pure as @pure and nothrow 
as @nothrow. I can't think of any other facets that would warrant 
semi-indefinite delay.

Re: @safe(bool)

[Jonathan M Davis via Digitalmars-d]

On Friday, August 18, 2017 03:08:07 Nicholas Wilson via Digitalmars-d wrote:
> On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis wrote:
> If you think that then I have clearly failed to express the DIP
> at all.
> It solves exactly that. I completely fail to see how it is a
> detriment to anything.
> The 'whole pile of other stuff' is reduced in further revisions
> to the DIP.

IMHO, the problem that needs solving is that you can't negate attributes,
making stuff like

final:

problematic. DIP 1012 goes way beyond that, and I don't think that that
extra stuff is at all worth having, and I do think that it's detrimental.
For instance, as it stands, it's relatively easy to figure out whether @safe
has been explicitly applied. You can look on the function and look for
@safe: or @safe {} which affects it. The same goes for other attributes. But
as soon as you can do stuff like create new attributes that combine
attributes, you lose that completely. Suddenly. you have to worry about
whatever attributes someone came up on their own for their project which
apply @safe or final or @nogc or whatever. You can no longer search or grep
for an attribute like @safe to see whether it applies. Similarly, having it
be possible to alter the default attributes globally is incredibly bad IMHO.
Suddenly, whether your module compiles or not could depend on what settings
someone used for the default attributes. That should not be controlled
externally. It should be part of the module just like whether a function or
variable is const or not is part of the module and not defined externally.
IMHO, it makes no sense whatsoever to have something external control
attributes any more than it makes sense to control the return types or
constness of symbols externally. That should be part of the
declarations/definitions of the symbols in question. And slapping something
like @safe: at the top of the module solves the problem of applying
attributes to an entire module right now just fine except for the fact that
you can't negate attributes, meaning that aside from the few that have
multiple states (namely, the @safety and access level attributes), you can't
alter the attributes on specific functions if you mark the whole module with
a particular attribute. So, we really should have a solution for negating
attributes, but I don't at all agree that the rest of what DIP 1012 is
trying to do is beneficial.

I honestly think that what DIP 1012 is trying to do beyond making it
possible to negate attributes is going to make the language worse and code
harder to maintain. Yes, it will enable some things that you can't do now,
but for the most part, I don't think that those things should be enabled. I
don't want to have to deal with folks complaining that my library doesn't
work right, because they tried a different default for the attributes with
it. I don't want to have to worry about trying to get someone else's code to
work because they assumed something about the default attributes that does
not hold in my case. I don't want to have to track down every custom
attribute that someone came up with just to see whether they actually apply
attributes like @safe or nothrow, just so that I can see whether those
attributes apply. I should be able to look at a module and see which
attributes have been applied to the functions in that module without having
to go searching elsewhere.

IMHO, what needs to be solved with the built-in attributes, is the ability
to negate the ones that don't have multiple states. With that, what we have
now will work just fine. The rest is completely undesirable.

- Jonathan M Davis

Re: @safe(bool)

[Timon Gehr via Digitalmars-d]

On 18.08.2017 17:16, bitwise wrote:

On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis wrote:

[...]

- Jonathan M Davis


Makes sense to me.

The first question that comes to mind is if the extra generality 
provided by DIP 1012 is actually useful, let alone, worth breaking 
changes. The rationale section of the DIP only mentions negating 
attributes, which is easily accomplished with what I suggested. Unless 
that section is expanded with additional practical use cases, then it 
doesn't seem worth the trouble to me.

...


It's a vastly better design, because it does not try to overfit to a 
single use case. E.g. it allows abstracting over attributes. You can 
have an alias that contains sequences of attributes and then apply the 
summary:


alias naughty = AliasSeq!(impure,system,throws,gc);
alias nice = AliasSeq!(pure,safe,nothrow,nogc);

@nice void foo();
@naughty void bar();


The DIP mentions tagging a module declaration with default attributes. 
If the whole purpose of the DIP is to allow for negating attributes, why 
would you even need this change, when the DIP would effectively make it 
ok to put "@nogc: @safe: @etc:" at the top of the file?


My suggestion does not cover "inferred" as discussed in the DIP, but 
that could be achieved by letting something like "@default" reset all 
attributes for a given symbol.


I'll concede that DIP1012 makes more logical sense than the current 
state of things, but it seems like something that would be best achieved 
during a transition to a subsequent language version. It seems 
commonplace here, to discard suggestions based on their current 
viability, when it may be better to add them to a feature backlog that 
could be considered when talking about the possibility of a D3.





There are non-awkward backwards-compatible ways to implement DIP 1012.

Re: @safe(bool)

[bitwise via Digitalmars-d]

On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis wrote:

[...]

- Jonathan M Davis


Makes sense to me.

The first question that comes to mind is if the extra generality 
provided by DIP 1012 is actually useful, let alone, worth 
breaking changes. The rationale section of the DIP only mentions 
negating attributes, which is easily accomplished with what I 
suggested. Unless that section is expanded with additional 
practical use cases, then it doesn't seem worth the trouble to me.


The DIP mentions tagging a module declaration with default 
attributes. If the whole purpose of the DIP is to allow for 
negating attributes, why would you even need this change, when 
the DIP would effectively make it ok to put "@nogc: @safe: @etc:" 
at the top of the file?


My suggestion does not cover "inferred" as discussed in the DIP, 
but that could be achieved by letting something like "@default" 
reset all attributes for a given symbol.


I'll concede that DIP1012 makes more logical sense than the 
current state of things, but it seems like something that would 
be best achieved during a transition to a subsequent language 
version. It seems commonplace here, to discard suggestions based 
on their current viability, when it may be better to add them to 
a feature backlog that could be considered when talking about the 
possibility of a D3.

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis wrote:

On Thursday, August 17, 2017 19:21:16 Timon Gehr via
That makes little sense to me, as DIP 1012 is strictly more 
general.


Whereas this solves the problem with DIP 1012 claims to be 
solving without adding a bunch of extra stuff that IMHO makes 
the built-in attributes more complicated for no real benefit as 
well as having some stuff in it that would effectively split 
the language into multiple variants where code will compile 
with some but not others (most notably, allowing for the 
default @safety level to be globally altered as opposed to 
doing something nice and portable like @safe: at the top of a 
module).


As I explained in that thread it adds very little complication, 
keyword like attributes become enum; last applied wins. If 
anything its reduces complexity as attributes, both builtin and 
user defined, become regular attributes. W.r.t global altering, I 
expect that it would be used by applications (rarely, e.g. 
embedded environments for nothrow nogc final) not libraries. It 
is also only part of the DIP.



As I explained in the initial discussion in DIP 1012,
it does a whole pile of stuff that has nothing to do with its 
stated goal, and I think that most of the other stuff that it 
does is detrimental, whereas if what's proposed here were 
implemented for more than just @safe, it would actually solve 
the stated goal of allowing attributes to be negated and thus 
fix the problem that doing something like putting final: at the 
top of a class can't be undone.


If you think that then I have clearly failed to express the DIP 
at all.
It solves exactly that. I completely fail to see how it is a 
detriment to anything.
The 'whole pile of other stuff' is reduced in further revisions 
to the DIP.


Andrei previously proposed essentially what the OP proposed, 
but no DIP was ever created for it, and it's never happened. It 
probably would stand a decent chance of making it through 
though, since it solves a real problem, and Andrei has 
previously shown interest in this solution.


And there was real interest in DIP 1012, which was the whole 
reason I wrote it, and

I reject your notion that DIP 1012 does not solve a problem.

Re: @safe(bool)

[Jonathan M Davis via Digitalmars-d]

On Thursday, August 17, 2017 19:21:16 Timon Gehr via Digitalmars-d wrote:
> On 17.08.2017 18:36, HyperParrow wrote:
> > On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:
> >> This came to mind while working on a set of containers.
> >>
> >> [...]
> >> One solution could be this:
> >>
> >> struct Container(T, bool safetyOn = true)
> >> {
> >>
> >> static if(safe)
> >>
> >> RefCounted!(T[]) data;
> >>
> >> else
> >>
> >> T[] data;
> >>
> >> auto opSlice() @safe(safetyOn) {
> >>
> >> return Range(data, 0, data.length);
> >>
> >> }
> >>
> >> }
> >>
> >> A similar solution could be applied to @nogc as well.
> >
> > Yeah, i like it more than
> > https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.
>
> That makes little sense to me, as DIP 1012 is strictly more general.

Whereas this solves the problem with DIP 1012 claims to be solving without
adding a bunch of extra stuff that IMHO makes the built-in attributes more
complicated for no real benefit as well as having some stuff in it that
would effectively split the language into multiple variants where code will
compile with some but not others (most notably, allowing for the default
@safety level to be globally altered as opposed to doing something nice and
portable like @safe: at the top of a module). As I explained in the initial
discussion in DIP 1012, it does a whole pile of stuff that has nothing to do
with its stated goal, and I think that most of the other stuff that it does
is detrimental, whereas if what's proposed here were implemented for more
than just @safe, it would actually solve the stated goal of allowing
attributes to be negated and thus fix the problem that doing something like
putting final: at the top of a class can't be undone.

Andrei previously proposed essentially what the OP proposed, but no DIP was
ever created for it, and it's never happened. It probably would stand a
decent chance of making it through though, since it solves a real problem,
and Andrei has previously shown interest in this solution.

- Jonathan M Davis

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Thursday, 17 August 2017 at 18:38:40 UTC, HypperParrow wrote:

On Thursday, 17 August 2017 at 17:21:16 UTC, Timon Gehr wrote:

On 17.08.2017 18:36, HyperParrow wrote:

On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:

[...]


Yeah, i like it more than 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.


That makes little sense to me, as DIP 1012 is strictly more 
general.


template safety(bool safetyOn){ // (this can even be in core)
static if(safetyOn) alias safety = FunctionSafety.safe;
else alias safety = FunctionSafety.system;
// else alias safety = infer!FunctionSafety; // even 
better!

}

struct Container(T, bool safetyOn = true){
static if(safe) RefCounted!(T[]) data;
else T[] data;

auto opSlice() @safety!safetyOn {
return Range(data, 0, data.length);
}
}


The application of DIP 1012 would have catastrophic effects on 
the current tooling but as usual nobody thinks to that.


How? In the Simplest terms DIP1012 replaces Keyword attributes 
with enums. Yes, libdparse would have to be updated, but that is 
the case for any substantial DIP. Hardly 'catastrophic'.

Re: @safe(bool)

[Timon Gehr via Digitalmars-d]

On 17.08.2017 20:38, HypperParrow wrote:

On Thursday, 17 August 2017 at 17:21:16 UTC, Timon Gehr wrote:

On 17.08.2017 18:36, HyperParrow wrote:

On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:

[...]


Yeah, i like it more than 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.


That makes little sense to me, as DIP 1012 is strictly more general.

template safety(bool safetyOn){ // (this can even be in core)
static if(safetyOn) alias safety = FunctionSafety.safe;
else alias safety = FunctionSafety.system;
// else alias safety = infer!FunctionSafety; // even better!
}

struct Container(T, bool safetyOn = true){
static if(safe) RefCounted!(T[]) data;
else T[] data;

auto opSlice() @safety!safetyOn {
return Range(data, 0, data.length);
}
}


The application of DIP 1012 would have catastrophic effects on the 
current tooling but as usual nobody thinks to that.


AFAICT, both of those claims are exaggerations. How exactly would it be 
"catastrophic"? This feature is easy to implement (basically, it just 
patches together a couple of existing pieces).

Re: @safe(bool)

[HypperParrow via Digitalmars-d]

On Thursday, 17 August 2017 at 17:21:16 UTC, Timon Gehr wrote:

On 17.08.2017 18:36, HyperParrow wrote:

On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:

[...]


Yeah, i like it more than 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.


That makes little sense to me, as DIP 1012 is strictly more 
general.


template safety(bool safetyOn){ // (this can even be in core)
static if(safetyOn) alias safety = FunctionSafety.safe;
else alias safety = FunctionSafety.system;
// else alias safety = infer!FunctionSafety; // even better!
}

struct Container(T, bool safetyOn = true){
static if(safe) RefCounted!(T[]) data;
else T[] data;

auto opSlice() @safety!safetyOn {
return Range(data, 0, data.length);
}
}


The application of DIP 1012 would have catastrophic effects on 
the current tooling but as usual nobody thinks to that.

Re: @safe(bool)

[Timon Gehr via Digitalmars-d]

On 17.08.2017 18:36, HyperParrow wrote:

On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:

This came to mind while working on a set of containers.

[...]
One solution could be this:

struct Container(T, bool safetyOn = true)
{
static if(safe)
RefCounted!(T[]) data;
else
T[] data;

auto opSlice() @safe(safetyOn) {
return Range(data, 0, data.length);
}
}

A similar solution could be applied to @nogc as well.


Yeah, i like it more than 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.


That makes little sense to me, as DIP 1012 is strictly more general.

template safety(bool safetyOn){ // (this can even be in core)
static if(safetyOn) alias safety = FunctionSafety.safe;
else alias safety = FunctionSafety.system;
// else alias safety = infer!FunctionSafety; // even better!
}

struct Container(T, bool safetyOn = true){
static if(safe) RefCounted!(T[]) data;
else T[] data;

auto opSlice() @safety!safetyOn {
return Range(data, 0, data.length);
}
}

Re: @safe(bool)

[Moritz Maxeiner via Digitalmars-d]

On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:
The only problem would be the lack of actual @safe annotations 
on the container, as they would only be applicable to one 
variant, and otherwise cause a compile-time error.

[...]


Shouldn't the already compiler derive the appropriate attributes 
(@safe/@system, @nogc) for functions inside templates?

Re: @safe(bool)

[HyperParrow via Digitalmars-d]

On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:

This came to mind while working on a set of containers.

[...]
One solution could be this:

struct Container(T, bool safetyOn = true)
{
static if(safe)
RefCounted!(T[]) data;
else
T[] data;

auto opSlice() @safe(safetyOn) {
return Range(data, 0, data.length);
}
}

A similar solution could be applied to @nogc as well.


Yeah, i like it more than 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.

@safe(bool)

[bitwise via Digitalmars-d]

This came to mind while working on a set of containers.

@safety often comes with a performance cost. For example, any 
container that wants to give out a range or iterator has to have 
a ref-counted or GC allocted payload to ensure safety. In a 
high-performance context though, the performance hit may be 
unacceptable.


It's fairly easy to make a container that toggles it's 
implementation between  ref-counted, GC, or raw pointers/arrays, 
based on a template parameter. This would allow a single 
container to be used in both performance sensitive and safe 
contexts (in theory). The only problem would be the lack of 
actual @safe annotations on the container, as they would only be 
applicable to one variant, and otherwise cause a compile-time 
error.


One solution could be this:

struct Container(T, bool safetyOn = true)
{
static if(safe)
RefCounted!(T[]) data;
else
T[] data;

auto opSlice() @safe(safetyOn) {
return Range(data, 0, data.length);
}
}

A similar solution could be applied to @nogc as well.