www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - safe(bool)

reply bitwise <bitwise.pvt gmail.com> writes:
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.
Aug 17
next sibling parent reply HyperParrow <HyperParrow yayaherr.de> writes:
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.
Aug 17
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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); } }
Aug 17
next sibling parent reply HypperParrow <hp yayaherr.de> writes:
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.
Aug 17
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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).
Aug 17
prev sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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'.
Aug 17
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Aug 17
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Aug 17
next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Aug 18
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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 multiple states. 
 With that, what we have now will work just fine. The rest is 
 completely undesirable.
Again I reject that notion.
Aug 18
parent reply jmh530 <john.michael.hall gmail.com> writes:
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.
Aug 18
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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!
Aug 19
parent reply jmh530 <john.michael.hall gmail.com> writes:
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?
Aug 19
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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
Aug 19
parent reply jmh530 <john.michael.hall gmail.com> writes:
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.
Aug 19
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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 ;)
Aug 19
prev sibling parent Danni Coy via Digitalmars-d <digitalmars-d puremagic.com> writes:
 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.
Aug 20
prev sibling parent reply bitwise <bitwise.pvt gmail.com> writes:
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.
Aug 18
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Aug 18
parent reply bitwise <bitwise.pvt gmail.com> writes:
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.....
Aug 19
parent Guillaume Boucher <guillaume.boucher.d gmail.com> writes:
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.
Aug 19
prev sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Aug 18
parent reply bitwise <bitwise.pvt gmail.com> writes:
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.
Aug 19
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Aug 19
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 20 Aug 2017 00:29:11 +0000
schrieb Nicholas Wilson <iamthewilsonator hotmail.com>:

 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
Aug 22
prev sibling next sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
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?
Aug 17
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Aug 18
prev sibling next sibling parent reply Guillaume Boucher <guillaume.boucher.d gmail.com> writes:
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); }); }
Aug 19
parent reply bitwise <bitwise.pvt gmail.com> writes:
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?
Aug 19
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Aug 19
parent reply bitwise <bitwise.pvt gmail.com> writes:
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.
Aug 19
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Aug 19
parent bitwise <bitwise.pvt gmail.com> writes:
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 frustrated....but 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
Aug 20
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Aug 21
next sibling parent reply bitwise <bitwise.pvt gmail.com> writes:
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.
Aug 21
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Aug 21
parent reply bitwise <bitwise.pvt gmail.com> writes:
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.
Aug 22
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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.
Aug 22
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Aug 22
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Aug 22
prev sibling parent bitwise <bitwise.pvt gmail.com> writes:
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.
Aug 22
prev sibling parent reply bitwise <bitwise.pvt gmail.com> writes:
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.
Aug 22
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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?
Aug 23
parent reply bitwise <bitwise.pvt gmail.com> writes:
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 ;)
Aug 23
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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?
Aug 24
parent reply bitwise <bitwise.pvt gmail.com> writes:
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.
Aug 25
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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.
Aug 25
parent reply bitwise <bitwise.pvt gmail.com> writes:
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.
Aug 25
parent 12345swordy <alexanderheistermann gmail.com> writes:
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.
Aug 26
prev sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Aug 21
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Aug 21
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Aug 21
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Aug 22
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Aug 22