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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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?





 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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 

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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 

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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017