Re: @safe(bool)
On Saturday, 26 August 2017 at 02:19:53 UTC, bitwise wrote: On Saturday, 26 August 2017 at 01:13:56 UTC, 12345swordy wrote: On Friday, 25 August 2017 at 18:18:14 UTC, bitwise wrote: On Thursday, 24 August 2017 at 14:59:05 UTC, 12345swordy wrote: [...] How about actually answering the question instead of assuming that I can't look up the definition of any words? While your statement may sound nice to you, and to some others in this thread, that does not make it well-founded. It's not a statement it's a question. Stop beating around the bush and just answer it already. Ok..gonna have to assume your just trolling at this point. Then you don't mind me dismissing your position as you fail to provide specific examples that I requested.
Re: @safe(bool)
On Saturday, 26 August 2017 at 01:13:56 UTC, 12345swordy wrote: On Friday, 25 August 2017 at 18:18:14 UTC, bitwise wrote: On Thursday, 24 August 2017 at 14:59:05 UTC, 12345swordy wrote: [...] How about actually answering the question instead of assuming that I can't look up the definition of any words? While your statement may sound nice to you, and to some others in this thread, that does not make it well-founded. It's not a statement it's a question. Stop beating around the bush and just answer it already. Ok..gonna have to assume your just trolling at this point.
Re: @safe(bool)
On Friday, 25 August 2017 at 18:18:14 UTC, bitwise wrote: On Thursday, 24 August 2017 at 14:59:05 UTC, 12345swordy wrote: [...] How about actually answering the question instead of assuming that I can't look up the definition of any words? While your statement may sound nice to you, and to some others in this thread, that does not make it well-founded. It's not a statement it's a question. Stop beating around the bush and just answer it already.
Re: @safe(bool)
On Thursday, 24 August 2017 at 14:59:05 UTC, 12345swordy wrote: [...] How about actually answering the question instead of assuming that I can't look up the definition of any words? While your statement may sound nice to you, and to some others in this thread, that does not make it well-founded. What you said was nothing more than a statement of opinion that's as uselessly generic as "premature optimization is the root of all evil". If you look back at my posts, you can see several instances of me citing personal experience (using extension methods in C#) or trying to relate the situation to existing features (function overloading). If you have evidence or experience that directly contradicts my arguments, I'm all ears, but a statement of opinion alone is not helpful.
Re: @safe(bool)
On Thursday, 24 August 2017 at 01:38:50 UTC, bitwise wrote: On Wednesday, 23 August 2017 at 13:28:37 UTC, 12345swordy wrote: On Wednesday, 23 August 2017 at 02:24:51 UTC, bitwise wrote: [...] Platitudes cause poor language design, not the completely reasonable expectation of good tools. And who is "Platitude" here specifically? http://lmgtfy.com/?q=platitude ;) How about actually answering the question instead of assuming that I can't look up the definition of any words?
Re: @safe(bool)
On Wednesday, 23 August 2017 at 13:28:37 UTC, 12345swordy wrote: On Wednesday, 23 August 2017 at 02:24:51 UTC, bitwise wrote: [...] Platitudes cause poor language design, not the completely reasonable expectation of good tools. And who is "Platitude" here specifically? http://lmgtfy.com/?q=platitude ;)
Re: @safe(bool)
On Wednesday, 23 August 2017 at 02:24:51 UTC, bitwise wrote: On Tuesday, 22 August 2017 at 19:46:00 UTC, 12345swordy wrote: On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote: On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote: [...] [...] There was a time that people would write code with even modest performance requirements in assembler for fear of what the compiler would spit out, but that's in the past, as is the notion of trying to develop without an IDE. You shouldn't rely on an IDE to compensate poor language design. That is coming from a guy who prefers IDE's. Platitudes cause poor language design, not the completely reasonable expectation of good tools. And who is "Platitude" here specifically?
Re: @safe(bool)
On Tuesday, 22 August 2017 at 19:56:46 UTC, Timon Gehr wrote: On 22.08.2017 21:46, 12345swordy wrote: On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote: On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote: [...] If you need an IDE to figure out what your code is doing, that's an epic fail IMHO. Walter has made similar statements on several occasions. There was a time that people would write code with even modest performance requirements in assembler for fear of what the compiler would spit out, but that's in the past, as is the notion of trying to develop without an IDE. You shouldn't rely on an IDE to compensate poor language design. That is coming from a guy who prefers IDE's. I disagree with both the notion that this is poor language design and that an IDE is required to make sense out of code that uses the new feature. "Required" is a bit of a strong word here. In the absence of good practice, any language feature can be abused to make code confusing. Function overloading is a good example of a feature that is usable as is, but made much better with a good IDE. But the same way I wouldn't name every function in a class "performAction" and pass a 50 member enum to it to tell it what to actually do, I wouldn't have more than 4-5 different types of function attribute combinations, and if I did, I wouldn't spread them out among 10 different files. What little extra effort it takes to look up the attributes of a function in an atmosphere of good practice can easily be made up for with good tools, and no one _has_ to use bundled up attributes.
Re: @safe(bool)
On Tuesday, 22 August 2017 at 19:46:00 UTC, 12345swordy wrote: On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote: On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote: [...] If you need an IDE to figure out what your code is doing, that's an epic fail IMHO. Walter has made similar statements on several occasions. There was a time that people would write code with even modest performance requirements in assembler for fear of what the compiler would spit out, but that's in the past, as is the notion of trying to develop without an IDE. You shouldn't rely on an IDE to compensate poor language design. That is coming from a guy who prefers IDE's. Platitudes cause poor language design, not the completely reasonable expectation of good tools.
Re: @safe(bool)
On Tuesday, 22 August 2017 at 19:56:46 UTC, Timon Gehr wrote: I disagree with both the notion that this is poor language design and that an IDE is required to make sense out of code that uses the new feature. Indeed, I can't imagine a DIP suggesting to make core regular attributes, keyword like getting very far had those attributes been added after we got UDAs. While IDEs may be able to show you instantly what attributes a function has, so would the compiler (in the form of an errors message if you got it wrong, quality of said message notwithstanding), documentation, any dcd based tooling (or any other tools that can do symbol resolution) and code searches. If the tooling is insufficient for this use case, then it should be improved as this is a problem that is able to be solved completely by tooling. If you choose not to use the tooling, and it would solve this problem, then that is fine, but I don't think we should limit the design of the language because of that.
Re: @safe(bool)
On 22.08.2017 21:46, 12345swordy wrote: On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote: On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote: [...] If you need an IDE to figure out what your code is doing, that's an epic fail IMHO. Walter has made similar statements on several occasions. There was a time that people would write code with even modest performance requirements in assembler for fear of what the compiler would spit out, but that's in the past, as is the notion of trying to develop without an IDE. You shouldn't rely on an IDE to compensate poor language design. That is coming from a guy who prefers IDE's. I disagree with both the notion that this is poor language design and that an IDE is required to make sense out of code that uses the new feature.
Re: @safe(bool)
On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote: On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote: [...] If you need an IDE to figure out what your code is doing, that's an epic fail IMHO. Walter has made similar statements on several occasions. There was a time that people would write code with even modest performance requirements in assembler for fear of what the compiler would spit out, but that's in the past, as is the notion of trying to develop without an IDE. You shouldn't rely on an IDE to compensate poor language design. That is coming from a guy who prefers IDE's.
Re: @safe(bool)
On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote: [...] If you need an IDE to figure out what your code is doing, that's an epic fail IMHO. Walter has made similar statements on several occasions. There was a time that people would write code with even modest performance requirements in assembler for fear of what the compiler would spit out, but that's in the past, as is the notion of trying to develop without an IDE.
Re: @safe(bool)
On Tuesday, August 22, 2017 09:11:13 Steven Schveighoffer via Digitalmars-d wrote: > On 8/21/17 9:20 PM, Jonathan M Davis via Digitalmars-d wrote: > > Regardless, it means that I would need to run a tool to figure out which > > attributes actually applied to a function rather than just reading it > > like I could do now. And the fact that this is can be done with UDAs > > right now is _not_ a plus. I can understand wanting to reduce the > > number of attributes being manually applied to functions, but I think > > that hiding them with aliases and/or combined attributes is a > > maintenance nightmare and would argue that it's just plain bad > > practice. > > Not for or against the DIP, but this is already the case, due to block > attributes. I have to search around the file to find out whether pure: > is at the top, etc. In fact, I've made recommendations many times on PRs > to add an attribute to a function, to find out it's already handled at > the top. > > I would think documentation generation should solve the issues. Honestly, I tend to be against block attributes for this very reason, but at least with block attributes, you can grep/search the file and find the information. With this DIP, you potentially have to go looking in other libraries to figure out which attributes actually apply, and you have to track down every attribute on a function just to figure out whether a built-in attribute applies to it. And I bet the documentation generation (at least as it stands) would just put the custom attributes on there and not translate them to their constituent attributes. But even if it put all of the attributes on there individually, honestly, I think that it's a huge negative if I have to run the documentation generation to figure out what some code is doing. IMHO, I should be able to read the code and see what it's doing without running extra tools or searching through several other projects. Sometimes (particularly with more complicated code where you have to understand other functionality to understand the stuff in front of you), life doesn't work that way, but that should be the goal. And aliasing and combining attributes goes completely against that goal. Stuff like block attributes already harm it, but at least they're localized. - Jonathan M Davis
Re: @safe(bool)
On 8/21/17 9:20 PM, Jonathan M Davis via Digitalmars-d wrote: Regardless, it means that I would need to run a tool to figure out which attributes actually applied to a function rather than just reading it like I could do now. And the fact that this is can be done with UDAs right now is _not_ a plus. I can understand wanting to reduce the number of attributes being manually applied to functions, but I think that hiding them with aliases and/or combined attributes is a maintenance nightmare and would argue that it's just plain bad practice. Not for or against the DIP, but this is already the case, due to block attributes. I have to search around the file to find out whether pure: is at the top, etc. In fact, I've made recommendations many times on PRs to add an attribute to a function, to find out it's already handled at the top. I would think documentation generation should solve the issues. -Steve
Re: @safe(bool)
Am Sun, 20 Aug 2017 00:29:11 + schrieb Nicholas Wilson : > On Saturday, 19 August 2017 at 17:10:54 UTC, bitwise wrote: > > I'm still concerned about having to read code that's laced full > > of custom attributes, the resolution of which may span several > > files, templates, etc. > > > > I also think this type of thing could have a detrimental effect > > on modularity when you end up having to include "myAttribs.d" > > in every single file you want to work on. I would much rather > > have a flexible in-language solution, or a solution that didn't > > require me to define my own attributes. > > Having worked on a project with a lot of attributes, my > suggestion would be to import it via a package.d, you'll be > importing that anyway. +1 A bigger project /usually/ has some default imports. Typical use cases are unifying compiler versions and architectures, back-porting new Phobos features and custom error handling and logging. For example, in dub the modules in the "internal" package are imported into most of the bigger modules. You can also create a file template with documentation header, license and default imports if you need to create a lot of modules. -- Marco
Re: @safe(bool)
On Tuesday, 22 August 2017 at 01:20:13 UTC, Jonathan M Davis wrote: On Tuesday, August 22, 2017 01:01:15 Nicholas Wilson via Digitalmars-d wrote: That attributes are combinable and aliasable are nice side effects of being regular attributes which in general are one of the main foci of the DIP (the other being fixing the non-invertibility). Which is precisely why I don't like it. Fixing non-invertibility is great. I don't like any of the rest. Any editor that has dcd (or other tooling) support should be able to immediately resolve which aliases refer to what as its only symbol resolution. Yes it won't be able to do inference but it can't under the current system either. Regardless, it means that I would need to run a tool to figure out which attributes actually applied to a function rather than just reading it like I could do now. And the fact that this is can be done with UDAs right now is _not_ a plus. I can understand wanting to reduce the number of attributes being manually applied to functions, but I think that hiding them with aliases and/or combined attributes is a maintenance nightmare and would argue that it's just plain bad practice. - Jonathan M Davis Then we shall just have to agree to disagree. I am of the opinion that they are very useful properties of UDAs and that's part of why I wrote that DIP.
Re: @safe(bool)
On Tuesday, August 22, 2017 01:01:15 Nicholas Wilson via Digitalmars-d wrote: > On Monday, 21 August 2017 at 08:09:25 UTC, Jonathan M Davis wrote: > > Except that someone could then be pulling in attributes from > > 3rd party libraries and using those, meaning that you'll > > potentially have to go digging through other libraries just to > > figure out whether a function is being marked with @safe or > > not. You get some of that pain with any custom attribute, but > > currently, the built-in attributes avoid it completely, and > > being able to combine attributes makes it far worse, since then > > you potentially have to go searching through a chain of > > declarations to figure out which attributes are actually being > > used. I can understand folks wanting to reduce how many > > attributes they have to manually put on functions, but I think > > that it risks being a maintenance nightmare to have to deal > > with combined or aliased attributes. I would _much_ rather see > > each attribute applied individually, because it's far easier to > > figure out what's going on that way. We already have enough > > problems figuring out which attributes are in play when dealing > > with attribute inference. I _really_ don't want to see aliasing > > and combining added to the mix - especially with the built-in > > attributes. And that seems to be one of if not the main > > motivation of the DIP. > > > > - Jonathan M Davis > > That attributes are combinable and aliasable are nice side > effects of being regular attributes which in general are one of > the main foci of the DIP (the other being fixing the > non-invertibility). Which is precisely why I don't like it. Fixing non-invertibility is great. I don't like any of the rest. > Any editor that has dcd (or other tooling) support should be able > to immediately resolve which aliases refer to what as its only > symbol resolution. Yes it won't be able to do inference but it > can't under the current system either. Regardless, it means that I would need to run a tool to figure out which attributes actually applied to a function rather than just reading it like I could do now. And the fact that this is can be done with UDAs right now is _not_ a plus. I can understand wanting to reduce the number of attributes being manually applied to functions, but I think that hiding them with aliases and/or combined attributes is a maintenance nightmare and would argue that it's just plain bad practice. - Jonathan M Davis
Re: @safe(bool)
On Monday, 21 August 2017 at 08:09:25 UTC, Jonathan M Davis wrote: Except that someone could then be pulling in attributes from 3rd party libraries and using those, meaning that you'll potentially have to go digging through other libraries just to figure out whether a function is being marked with @safe or not. You get some of that pain with any custom attribute, but currently, the built-in attributes avoid it completely, and being able to combine attributes makes it far worse, since then you potentially have to go searching through a chain of declarations to figure out which attributes are actually being used. I can understand folks wanting to reduce how many attributes they have to manually put on functions, but I think that it risks being a maintenance nightmare to have to deal with combined or aliased attributes. I would _much_ rather see each attribute applied individually, because it's far easier to figure out what's going on that way. We already have enough problems figuring out which attributes are in play when dealing with attribute inference. I _really_ don't want to see aliasing and combining added to the mix - especially with the built-in attributes. And that seems to be one of if not the main motivation of the DIP. - Jonathan M Davis That attributes are combinable and aliasable are nice side effects of being regular attributes which in general are one of the main foci of the DIP (the other being fixing the non-invertibility). Any editor that has dcd (or other tooling) support should be able to immediately resolve which aliases refer to what as its only symbol resolution. Yes it won't be able to do inference but it can't under the current system either.
Re: @safe(bool)
On Tuesday, August 22, 2017 00:21:16 bitwise via Digitalmars-d wrote: > On Monday, 21 August 2017 at 08:09:25 UTC, Jonathan M Davis wrote: > > you potentially have to go searching through a chain of > > declarations to figure out which attributes are actually being > > used. > > A good IDE should give you this info if you hover over a > function. I realize D's tool support is spotty at the moment, but > it seems like the kind of think that's ok to be optimistic about. If you need an IDE to figure out what your code is doing, that's an epic fail IMHO. Walter has made similar statements on several occasions. D was originally designed in such a way that IDEs should not be necessary (e.g. it tries to avoid a lot of the boilerplate code that is typical in Java programs). Most of the folks around here do not use IDEs. I use (g)vim as my code editor, and I have no desire to use an IDE. I should be able to figure out what's going on just by looking at the code, and having to go spelunking to figure out which attributes really apply because they're hidden behind aliases or combined in other attributes is just wasting my time IMHO. As long as the attributes are applied directly without being renamed (be it directly on the function or to the module as a whole), then the situation is quite tractable, but if we end up with aliased attributes and combined attributes, that goes completely out the window. - Jonathan M Davis
Re: @safe(bool)
On Monday, 21 August 2017 at 08:09:25 UTC, Jonathan M Davis wrote: you potentially have to go searching through a chain of declarations to figure out which attributes are actually being used. A good IDE should give you this info if you hover over a function. I realize D's tool support is spotty at the moment, but it seems like the kind of think that's ok to be optimistic about.
Re: @safe(bool)
On Monday, August 21, 2017 10:41:49 Danni Coy via Digitalmars-d wrote: > > For instance, as it stands, it's relatively easy to figure out whether > > @safe > > has been explicitly applied. You can look on the function and look for > > @safe: or @safe {} which affects it. The same goes for other attributes. > > But > > as soon as you can do stuff like create new attributes that combine > > attributes, you lose that completely. Suddenly. you have to worry about > > whatever attributes someone came up on their own for their project which > > apply @safe or final or @nogc or whatever. You can no longer search or > > grep for an attribute like @safe to see whether it applies. > > you can still search or grep but it's now a two step process. when you > grep the @safe attribute you will find the custom attribute declaration. > you then search for the custom declaration. You need to do the first step > exactly once for each codebase (unless you forget). > > It's more diffucult but only a little bit. Except that someone could then be pulling in attributes from 3rd party libraries and using those, meaning that you'll potentially have to go digging through other libraries just to figure out whether a function is being marked with @safe or not. You get some of that pain with any custom attribute, but currently, the built-in attributes avoid it completely, and being able to combine attributes makes it far worse, since then you potentially have to go searching through a chain of declarations to figure out which attributes are actually being used. I can understand folks wanting to reduce how many attributes they have to manually put on functions, but I think that it risks being a maintenance nightmare to have to deal with combined or aliased attributes. I would _much_ rather see each attribute applied individually, because it's far easier to figure out what's going on that way. We already have enough problems figuring out which attributes are in play when dealing with attribute inference. I _really_ don't want to see aliasing and combining added to the mix - especially with the built-in attributes. And that seems to be one of if not the main motivation of the DIP. - Jonathan M Davis
Re: @safe(bool)
> For instance, as it stands, it's relatively easy to figure out whether > @safe > has been explicitly applied. You can look on the function and look for > @safe: or @safe {} which affects it. The same goes for other attributes. > But > as soon as you can do stuff like create new attributes that combine > attributes, you lose that completely. Suddenly. you have to worry about > whatever attributes someone came up on their own for their project which > apply @safe or final or @nogc or whatever. You can no longer search or grep > for an attribute like @safe to see whether it applies. > > you can still search or grep but it's now a two step process. when you grep the @safe attribute you will find the custom attribute declaration. you then search for the custom declaration. You need to do the first step exactly once for each codebase (unless you forget). It's more diffucult but only a little bit.
Re: @safe(bool)
On Sunday, 20 August 2017 at 01:33:00 UTC, Nicholas Wilson wrote: I'm not quite sure how this would lead to a loss of modularity? Not sure if modularity is exactly the right word. The problem would be akin to extension methods in C#, or even a useful set of UFC's in D. So, imagine you decide you need DateTime.LastWeek() or something similar. This turns out to be something you end up needing in most of your projects. So first of all, you're now required to start bringing this file into every project you work on. This is already annoying. Then, one day, you decide you also need DateTime.FortnightAgo(). So you add it to the file, except that all the other versions are now out of sync. You think, maybe I should have made a repository!? First of all, too late. Second, you now have to clone a repo into all your new projects instead of dragging and dropping a file, and update the repo every time you want to work on the project in case anything changed. At this point, any reasonable person would be frustratedbut wait...you also need some extensions for Math as well, which are not necessarily related to the extensions for DateTime. I suppose you could start throwing together your own small support library with all of these things in there... But wait...some of the extensions are platform specific *facepalm*. So eventually, you end up with a chart like this[1] describing which of these libs are in each of your projects. The catch is, that a lot of the time, the things you make are these extensions for are so ubiquitous that they should probably just be included in the language, or standard library. An easy example is the million different variations of C++ "thread", "mutex" and "hashtable" that were built while the C++ community took a coffee break from 1998 to 2011 ;) I think I've painted the picture sufficiently at this point. [1] http://i.imgur.com/cQxxQJs.png
Re: @safe(bool)
On Sunday, 20 August 2017 at 02:53:14 UTC, jmh530 wrote: On Sunday, 20 August 2017 at 00:55:41 UTC, Nicholas Wilson wrote: Sorry, I was referring to preconfigurations in druntime like https://github.com/dlang/DIPs/pull/89/files#diff-26bf588c0174e6cd0fe3d4af615bebdaL60 So modifying core.attribute.defaultAttributeSet in the runtime is the only way to change the default attribute set, Yes, whether that be a custom runtime or through version conditions that define core.attribute.defaultAttributeSet. but one could create a custom attribute that they just use as needed. So one could just look at the top of the file to see if the code has something like @myDefaultAttributeSet. Yes. Hopefully a bit more descriptive though ;)
Re: @safe(bool)
On Sunday, 20 August 2017 at 00:55:41 UTC, Nicholas Wilson wrote: Sorry, I was referring to preconfigurations in druntime like https://github.com/dlang/DIPs/pull/89/files#diff-26bf588c0174e6cd0fe3d4af615bebdaL60 So modifying core.attribute.defaultAttributeSet in the runtime is the only way to change the default attribute set, but one could create a custom attribute that they just use as needed. So one could just look at the top of the file to see if the code has something like @myDefaultAttributeSet.
Re: @safe(bool)
On Sunday, 20 August 2017 at 01:05:39 UTC, bitwise wrote: This is indeed, a nice solution. I am a _bit_ worried about abuse, and loss of modularity, but aside from that, I think it's a better solution overall. All features in the style of "I know what I'm doing, just let me do it!" (=void, @trusted ect.) are open to abuse but I don't think we've ever had problems with them. They tend to be used sparingly and only when absolutely necessary. I'm not quite sure how this would lead to a loss of modularity? The only downside is that the second form leaves itself open to Easily fixed with a template constraint, right? True, too early in the morning. zzz. This could potentially render a large portion of the projects on code.dlang.org broken though. What would be nice, is if code.dlang.org regularly built all the projects, and notified the authors of the breakage, possibly sending a list of recent compiler changes as well. I don' think It would break too much, but we have @future to mitigate all potential breakages from this DIP. Autotesting is obviously desirable.
Re: @safe(bool)
On Sunday, 20 August 2017 at 00:49:28 UTC, Nicholas Wilson wrote: [...] With DIP 1012 you should be able to go struct Container(T, bool safetyOn = true) { static if(safe) RefCounted!(T[]) data; else T[] data; auto opSlice() @safeIf!safetyOn { return Range(data, 0, data.length); } } template safeIf(bool cond) { static if (cond) alias safeIf = AliasSeq!(safe); else alias safeIf = AliasSeq!(); } or even just struct Container(T, FunctionSafety safetyOn = safe) { static if(safe) RefCounted!(T[]) data; else T[] data; auto opSlice() @safetyOn { return Range(data, 0, data.length); } } Container!int foo; // Container!(int, safe) Container!(int, system) bar; This is indeed, a nice solution. I am a _bit_ worried about abuse, and loss of modularity, but aside from that, I think it's a better solution overall. The only downside is that the second form leaves itself open to Easily fixed with a template constraint, right? This could potentially render a large portion of the projects on code.dlang.org broken though. What would be nice, is if code.dlang.org regularly built all the projects, and notified the authors of the breakage, possibly sending a list of recent compiler changes as well.
Re: @safe(bool)
On Saturday, 19 August 2017 at 20:39:07 UTC, jmh530 wrote: On Saturday, 19 August 2017 at 13:09:41 UTC, Nicholas Wilson wrote: Hacking the runtime is certainly one way to achieve changing the default attributes. However having them as regular attributes means that is is possible to do configuration by version statements, which is a) much easier than hacking the runtime and b) causes much less fragmentation. This may not be so elegant...but what if one could only take an alias of these in core.attributes or in a package.d file? At least that way people would know where to look if widespread changes are made? Sorry, I was referring to preconfigurations in druntime like https://github.com/dlang/DIPs/pull/89/files#diff-26bf588c0174e6cd0fe3d4af615bebdaL60
Re: @safe(bool)
On Saturday, 19 August 2017 at 19:15:25 UTC, bitwise wrote: On Saturday, 19 August 2017 at 18:22:58 UTC, Guillaume Boucher wrote: On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote: In a high-performance context though, the performance hit may be unacceptable. Well in those super rare situations, there's always the workaround with mixins: Those situations are not rare. mixin template funcWithAttr(string decl, string attributes, string code) { pragma(msg, "<<<" ~ code ~ ">>>"); mixin(decl ~ attributes ~ "{" ~ code ~" }"); } struct Container(T, bool safetyOn = true) { static if(safe) RefCounted!(T[]) data; else T[] data; mixin funcWithAttr!("auto opSlice()", safetyOn ? "@safe" : "", q{ return Range(data, 0, data.length); }); } Really? With DIP 1012 you should be able to go struct Container(T, bool safetyOn = true) { static if(safe) RefCounted!(T[]) data; else T[] data; auto opSlice() @safeIf!safetyOn { return Range(data, 0, data.length); } } template safeIf(bool cond) { static if (cond) alias safeIf = AliasSeq!(safe); else alias safeIf = AliasSeq!(); } or even just struct Container(T, FunctionSafety safetyOn = safe) { static if(safe) RefCounted!(T[]) data; else T[] data; auto opSlice() @safetyOn { return Range(data, 0, data.length); } } Container!int foo; // Container!(int, safe) Container!(int, system) bar; The only downside is that the second form leaves itself open to Container!(int, trusted) quux; which is probably undesirable.
Re: @safe(bool)
On Saturday, 19 August 2017 at 17:10:54 UTC, bitwise wrote: I'm still concerned about having to read code that's laced full of custom attributes, the resolution of which may span several files, templates, etc. I also think this type of thing could have a detrimental effect on modularity when you end up having to include "myAttribs.d" in every single file you want to work on. I would much rather have a flexible in-language solution, or a solution that didn't require me to define my own attributes. Having worked on a project with a lot of attributes, my suggestion would be to import it via a package.d, you'll be importing that anyway.
Re: @safe(bool)
On Saturday, 19 August 2017 at 13:09:41 UTC, Nicholas Wilson wrote: Hacking the runtime is certainly one way to achieve changing the default attributes. However having them as regular attributes means that is is possible to do configuration by version statements, which is a) much easier than hacking the runtime and b) causes much less fragmentation. This may not be so elegant...but what if one could only take an alias of these in core.attributes or in a package.d file? At least that way people would know where to look if widespread changes are made?
Re: @safe(bool)
On Saturday, 19 August 2017 at 18:22:58 UTC, Guillaume Boucher wrote: On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote: In a high-performance context though, the performance hit may be unacceptable. Well in those super rare situations, there's always the workaround with mixins: Those situations are not rare. mixin template funcWithAttr(string decl, string attributes, string code) { pragma(msg, "<<<" ~ code ~ ">>>"); mixin(decl ~ attributes ~ "{" ~ code ~" }"); } struct Container(T, bool safetyOn = true) { static if(safe) RefCounted!(T[]) data; else T[] data; mixin funcWithAttr!("auto opSlice()", safetyOn ? "@safe" : "", q{ return Range(data, 0, data.length); }); } Really?
Re: @safe(bool)
On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote: In a high-performance context though, the performance hit may be unacceptable. Well in those super rare situations, there's always the workaround with mixins: mixin template funcWithAttr(string decl, string attributes, string code) { pragma(msg, "<<<" ~ code ~ ">>>"); mixin(decl ~ attributes ~ "{" ~ code ~" }"); } struct Container(T, bool safetyOn = true) { static if(safe) RefCounted!(T[]) data; else T[] data; mixin funcWithAttr!("auto opSlice()", safetyOn ? "@safe" : "", q{ return Range(data, 0, data.length); }); }
Re: @safe(bool)
On Saturday, 19 August 2017 at 16:02:27 UTC, bitwise wrote: We have to consider the potential for abuse. I don't like measuring features on the potential for abuse, but this feature cries for abuse. Even in the simpler form of your proposal. Let's say there are two functions with conditional @safe f(T)(...) @safe(!hasAliasing!T) {...} g(bool B)(...) @safe(B) {...} and we combine them into another function, h(T,bool B) @safe(!hasAliasing!T && B) { f(T)(...); g(B)(...); } then in the correct @safe specification there is an additional clause for every conditionally-safe function. This doesn't scale well. So the guideline would be to use your feature very rarely and only if it's obvious from the meaning of the template arguments; if it gets too complicated, just don't specify it. Which would mean the feature should only be used in few corner cases, and is thus not worth the cost of complicating the language. You already commented on the other usage of dip 1012, the @nice and @naughty attributes. They just don't scale in a similar way. C++ has had the same feature for some time: noexcept(true) means noexcept, noexcept(false) means an exception may be thrown (of course this works with any constant expressions). I just grepped through Boost and I have found 53 uses of noexcept(expression), from 5264 total uses of noexcept (excluding the math library). And Boost is one of those libraries that are overly precise with such things to a degree that the code becomes unreadable. In code outside of Boost and the standard library, noexcept(expression) it is basically unused.
Re: @safe(bool)
On Friday, 18 August 2017 at 23:48:05 UTC, Nicholas Wilson wrote: The only breaking changes are nothrow and pure get a leading '@'. They will go through a proper deprecation process and I will be very surprised if anything breaks. The new symbols added to core.attributes can use `@future` if need be to further reduce the likelihood of any breaking changes. While the difference in attribute style(@, or no @) isn't that hard to deal with in practice, I am definitely in favor of a more consistent scheme. The current inconsistency looks bad, and IMO, that's a big deal. It makes D look tacky, and easy to dismiss. How would you know what attributes were in effect before? It wouldn't matter if your intention was to clobber them anyways with @default. And if you only wanted to clobber @nogc, you could use @nogc(false), and it still wouldn't matter what the inferred attribute set was. I'm still concerned about having to read code that's laced full of custom attributes, the resolution of which may span several files, templates, etc. I also think this type of thing could have a detrimental effect on modularity when you end up having to include "myAttribs.d" in every single file you want to work on. I would much rather have a flexible in-language solution, or a solution that didn't require me to define my own attributes.
Re: @safe(bool)
On Friday, 18 August 2017 at 18:15:33 UTC, Timon Gehr wrote: [...] alias naughty = AliasSeq!(impure,system,throws,gc); alias nice = AliasSeq!(pure,safe,nothrow,nogc); @nice void foo(); @naughty void bar(); We have to consider the potential for abuse. For example, D's templates are great - but it doesn't mean that if you're making a math library, that you should template your matrix class on it's dimensions, just to fill it with static if's because half of the functionality only applies to a single dimension. Especially when you typically need 2-3 different versions at most(mat2, mat3, mat4). People do it though. If things did turn out to be as simple as the example you posted, then I could see it being a useful way to hide some of D's painful attribute bloat, but I've got a feeling we'd start seeing things like "nice", "nicer", "nicest", "niceInDebugModeButNotReleaseModeUnlessAssertsAreEnabled", etc.
Re: @safe(bool)
On Saturday, 19 August 2017 at 02:00:47 UTC, jmh530 wrote: On Saturday, 19 August 2017 at 00:37:06 UTC, Nicholas Wilson wrote: Having to change the default attributes will be a rare occurrence (embedded (nothrow, nogc final) security critical (safe). My reading of that updated DIP is that you can only change the default attributes by hacking on DRuntime. Hacking the runtime is certainly one way to achieve changing the default attributes. However having them as regular attributes means that is is possible to do configuration by version statements, which is a) much easier than hacking the runtime and b) causes much less fragmentation. I don't think we want to encourage people to change the default attributes, but I think its one of those features that we have in D for those who know what they're doing (e.g =void) and don't want to get in their way of doing so. If a project has a custom runtime, I would figure most people would mention it somewhere. I would hope so!
Re: @safe(bool)
On 18 August 2017 at 02:32, bitwise via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > This came to mind while working on a set of containers. > > @safety often comes with a performance cost. For example, any container > that wants to give out a range or iterator has to have a ref-counted or GC > allocted payload to ensure safety. In a high-performance context though, > the performance hit may be unacceptable. > This sounds like a job for `scope`. Eg, given a container, the function that returns the range/iterator should return a `scope` attributed range/iterator. This should insist that the lifetime of the range that is returned be no longer than the container that issued it. We've needed scope to address these issues for a very long time, and it finally arrived! I'm not sure how far it extends yet though, it's not well documented yet, and I haven't seen it get a lot of action. I'm not sure where the boundaries are.
Re: @safe(bool)
On Saturday, 19 August 2017 at 00:37:06 UTC, Nicholas Wilson wrote: Having to change the default attributes will be a rare occurrence (embedded (nothrow, nogc final) security critical (safe). My reading of that updated DIP is that you can only change the default attributes by hacking on DRuntime. If a project has a custom runtime, I would figure most people would mention it somewhere.
Re: @safe(bool)
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
Re: @safe(bool)
On Friday, 18 August 2017 at 15:16:55 UTC, bitwise wrote: On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis wrote: [...] - Jonathan M Davis Makes sense to me. The first question that comes to mind is if the extra generality provided by DIP 1012 is actually useful, let alone, worth breaking changes. It fixes the non-inverability. They become regular attributes instead of keywords. This has the effect of separating their definition from their usage allowing you to manipulate them like normal attributes, see https://github.com/dlang/DIPs/pull/89/ for the most recent revision. The only breaking changes are nothrow and pure get a leading '@'. They will go through a proper deprecation process and I will be very surprised if anything breaks. The new symbols added to core.attributes can use `@future` if need be to further reduce the likelihood of any breaking changes. The rationale section of the DIP only mentions negating attributes, which is easily accomplished with what I suggested. Unless that section is expanded with additional practical use cases, then it doesn't seem worth the trouble to me. The DIP mentions tagging a module declaration with default attributes. If the whole purpose of the DIP is to allow for negating attributes, why would you even need this change, when the DIP would effectively make it ok to put "@nogc: @safe: @etc:" at the top of the file? This is changed in pull #89. My suggestion does not cover "inferred" as discussed in the DIP, but that could be achieved by letting something like "@default" reset all attributes for a given symbol. How would you know what attributes were in effect before? I'll concede that DIP1012 makes more logical sense than the current state of things, but it seems like something that would be best achieved during a transition to a subsequent language version. It seems commonplace here, to discard suggestions based on their current viability, when it may be better to add them to a feature backlog that could be considered when talking about the possibility of a D3. Why? Breakage will be completely contained with transitional behaviour, i.e. the compiler will treat pure as @pure and nothrow as @nothrow. I can't think of any other facets that would warrant semi-indefinite delay.
Re: @safe(bool)
On Friday, August 18, 2017 03:08:07 Nicholas Wilson via Digitalmars-d wrote: > On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis wrote: > If you think that then I have clearly failed to express the DIP > at all. > It solves exactly that. I completely fail to see how it is a > detriment to anything. > The 'whole pile of other stuff' is reduced in further revisions > to the DIP. IMHO, the problem that needs solving is that you can't negate attributes, making stuff like final: problematic. DIP 1012 goes way beyond that, and I don't think that that extra stuff is at all worth having, and I do think that it's detrimental. For instance, as it stands, it's relatively easy to figure out whether @safe has been explicitly applied. You can look on the function and look for @safe: or @safe {} which affects it. The same goes for other attributes. But as soon as you can do stuff like create new attributes that combine attributes, you lose that completely. Suddenly. you have to worry about whatever attributes someone came up on their own for their project which apply @safe or final or @nogc or whatever. You can no longer search or grep for an attribute like @safe to see whether it applies. Similarly, having it be possible to alter the default attributes globally is incredibly bad IMHO. Suddenly, whether your module compiles or not could depend on what settings someone used for the default attributes. That should not be controlled externally. It should be part of the module just like whether a function or variable is const or not is part of the module and not defined externally. IMHO, it makes no sense whatsoever to have something external control attributes any more than it makes sense to control the return types or constness of symbols externally. That should be part of the declarations/definitions of the symbols in question. And slapping something like @safe: at the top of the module solves the problem of applying attributes to an entire module right now just fine except for the fact that you can't negate attributes, meaning that aside from the few that have multiple states (namely, the @safety and access level attributes), you can't alter the attributes on specific functions if you mark the whole module with a particular attribute. So, we really should have a solution for negating attributes, but I don't at all agree that the rest of what DIP 1012 is trying to do is beneficial. I honestly think that what DIP 1012 is trying to do beyond making it possible to negate attributes is going to make the language worse and code harder to maintain. Yes, it will enable some things that you can't do now, but for the most part, I don't think that those things should be enabled. I don't want to have to deal with folks complaining that my library doesn't work right, because they tried a different default for the attributes with it. I don't want to have to worry about trying to get someone else's code to work because they assumed something about the default attributes that does not hold in my case. I don't want to have to track down every custom attribute that someone came up with just to see whether they actually apply attributes like @safe or nothrow, just so that I can see whether those attributes apply. I should be able to look at a module and see which attributes have been applied to the functions in that module without having to go searching elsewhere. IMHO, what needs to be solved with the built-in attributes, is the ability to negate the ones that don't have multiple states. With that, what we have now will work just fine. The rest is completely undesirable. - Jonathan M Davis
Re: @safe(bool)
On 18.08.2017 17:16, bitwise wrote: On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis wrote: [...] - Jonathan M Davis Makes sense to me. The first question that comes to mind is if the extra generality provided by DIP 1012 is actually useful, let alone, worth breaking changes. The rationale section of the DIP only mentions negating attributes, which is easily accomplished with what I suggested. Unless that section is expanded with additional practical use cases, then it doesn't seem worth the trouble to me. ... It's a vastly better design, because it does not try to overfit to a single use case. E.g. it allows abstracting over attributes. You can have an alias that contains sequences of attributes and then apply the summary: alias naughty = AliasSeq!(impure,system,throws,gc); alias nice = AliasSeq!(pure,safe,nothrow,nogc); @nice void foo(); @naughty void bar(); The DIP mentions tagging a module declaration with default attributes. If the whole purpose of the DIP is to allow for negating attributes, why would you even need this change, when the DIP would effectively make it ok to put "@nogc: @safe: @etc:" at the top of the file? My suggestion does not cover "inferred" as discussed in the DIP, but that could be achieved by letting something like "@default" reset all attributes for a given symbol. I'll concede that DIP1012 makes more logical sense than the current state of things, but it seems like something that would be best achieved during a transition to a subsequent language version. It seems commonplace here, to discard suggestions based on their current viability, when it may be better to add them to a feature backlog that could be considered when talking about the possibility of a D3. There are non-awkward backwards-compatible ways to implement DIP 1012.
Re: @safe(bool)
On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis wrote: [...] - Jonathan M Davis Makes sense to me. The first question that comes to mind is if the extra generality provided by DIP 1012 is actually useful, let alone, worth breaking changes. The rationale section of the DIP only mentions negating attributes, which is easily accomplished with what I suggested. Unless that section is expanded with additional practical use cases, then it doesn't seem worth the trouble to me. The DIP mentions tagging a module declaration with default attributes. If the whole purpose of the DIP is to allow for negating attributes, why would you even need this change, when the DIP would effectively make it ok to put "@nogc: @safe: @etc:" at the top of the file? My suggestion does not cover "inferred" as discussed in the DIP, but that could be achieved by letting something like "@default" reset all attributes for a given symbol. I'll concede that DIP1012 makes more logical sense than the current state of things, but it seems like something that would be best achieved during a transition to a subsequent language version. It seems commonplace here, to discard suggestions based on their current viability, when it may be better to add them to a feature backlog that could be considered when talking about the possibility of a D3.
Re: @safe(bool)
On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis wrote: On Thursday, August 17, 2017 19:21:16 Timon Gehr via That makes little sense to me, as DIP 1012 is strictly more general. Whereas this solves the problem with DIP 1012 claims to be solving without adding a bunch of extra stuff that IMHO makes the built-in attributes more complicated for no real benefit as well as having some stuff in it that would effectively split the language into multiple variants where code will compile with some but not others (most notably, allowing for the default @safety level to be globally altered as opposed to doing something nice and portable like @safe: at the top of a module). As I explained in that thread it adds very little complication, keyword like attributes become enum; last applied wins. If anything its reduces complexity as attributes, both builtin and user defined, become regular attributes. W.r.t global altering, I expect that it would be used by applications (rarely, e.g. embedded environments for nothrow nogc final) not libraries. It is also only part of the DIP. As I explained in the initial discussion in DIP 1012, it does a whole pile of stuff that has nothing to do with its stated goal, and I think that most of the other stuff that it does is detrimental, whereas if what's proposed here were implemented for more than just @safe, it would actually solve the stated goal of allowing attributes to be negated and thus fix the problem that doing something like putting final: at the top of a class can't be undone. If you think that then I have clearly failed to express the DIP at all. It solves exactly that. I completely fail to see how it is a detriment to anything. The 'whole pile of other stuff' is reduced in further revisions to the DIP. Andrei previously proposed essentially what the OP proposed, but no DIP was ever created for it, and it's never happened. It probably would stand a decent chance of making it through though, since it solves a real problem, and Andrei has previously shown interest in this solution. And there was real interest in DIP 1012, which was the whole reason I wrote it, and I reject your notion that DIP 1012 does not solve a problem.
Re: @safe(bool)
On Thursday, August 17, 2017 19:21:16 Timon Gehr via Digitalmars-d wrote: > On 17.08.2017 18:36, HyperParrow wrote: > > On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote: > >> This came to mind while working on a set of containers. > >> > >> [...] > >> One solution could be this: > >> > >> struct Container(T, bool safetyOn = true) > >> { > >> > >> static if(safe) > >> > >> RefCounted!(T[]) data; > >> > >> else > >> > >> T[] data; > >> > >> auto opSlice() @safe(safetyOn) { > >> > >> return Range(data, 0, data.length); > >> > >> } > >> > >> } > >> > >> A similar solution could be applied to @nogc as well. > > > > Yeah, i like it more than > > https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md. > > That makes little sense to me, as DIP 1012 is strictly more general. Whereas this solves the problem with DIP 1012 claims to be solving without adding a bunch of extra stuff that IMHO makes the built-in attributes more complicated for no real benefit as well as having some stuff in it that would effectively split the language into multiple variants where code will compile with some but not others (most notably, allowing for the default @safety level to be globally altered as opposed to doing something nice and portable like @safe: at the top of a module). As I explained in the initial discussion in DIP 1012, it does a whole pile of stuff that has nothing to do with its stated goal, and I think that most of the other stuff that it does is detrimental, whereas if what's proposed here were implemented for more than just @safe, it would actually solve the stated goal of allowing attributes to be negated and thus fix the problem that doing something like putting final: at the top of a class can't be undone. Andrei previously proposed essentially what the OP proposed, but no DIP was ever created for it, and it's never happened. It probably would stand a decent chance of making it through though, since it solves a real problem, and Andrei has previously shown interest in this solution. - Jonathan M Davis
Re: @safe(bool)
On Thursday, 17 August 2017 at 18:38:40 UTC, HypperParrow wrote: On Thursday, 17 August 2017 at 17:21:16 UTC, Timon Gehr wrote: On 17.08.2017 18:36, HyperParrow wrote: On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote: [...] Yeah, i like it more than https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md. That makes little sense to me, as DIP 1012 is strictly more general. template safety(bool safetyOn){ // (this can even be in core) static if(safetyOn) alias safety = FunctionSafety.safe; else alias safety = FunctionSafety.system; // else alias safety = infer!FunctionSafety; // even better! } struct Container(T, bool safetyOn = true){ static if(safe) RefCounted!(T[]) data; else T[] data; auto opSlice() @safety!safetyOn { return Range(data, 0, data.length); } } The application of DIP 1012 would have catastrophic effects on the current tooling but as usual nobody thinks to that. How? In the Simplest terms DIP1012 replaces Keyword attributes with enums. Yes, libdparse would have to be updated, but that is the case for any substantial DIP. Hardly 'catastrophic'.
Re: @safe(bool)
On 17.08.2017 20:38, HypperParrow wrote: On Thursday, 17 August 2017 at 17:21:16 UTC, Timon Gehr wrote: On 17.08.2017 18:36, HyperParrow wrote: On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote: [...] Yeah, i like it more than https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md. That makes little sense to me, as DIP 1012 is strictly more general. template safety(bool safetyOn){ // (this can even be in core) static if(safetyOn) alias safety = FunctionSafety.safe; else alias safety = FunctionSafety.system; // else alias safety = infer!FunctionSafety; // even better! } struct Container(T, bool safetyOn = true){ static if(safe) RefCounted!(T[]) data; else T[] data; auto opSlice() @safety!safetyOn { return Range(data, 0, data.length); } } The application of DIP 1012 would have catastrophic effects on the current tooling but as usual nobody thinks to that. AFAICT, both of those claims are exaggerations. How exactly would it be "catastrophic"? This feature is easy to implement (basically, it just patches together a couple of existing pieces).
Re: @safe(bool)
On Thursday, 17 August 2017 at 17:21:16 UTC, Timon Gehr wrote: On 17.08.2017 18:36, HyperParrow wrote: On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote: [...] Yeah, i like it more than https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md. That makes little sense to me, as DIP 1012 is strictly more general. template safety(bool safetyOn){ // (this can even be in core) static if(safetyOn) alias safety = FunctionSafety.safe; else alias safety = FunctionSafety.system; // else alias safety = infer!FunctionSafety; // even better! } struct Container(T, bool safetyOn = true){ static if(safe) RefCounted!(T[]) data; else T[] data; auto opSlice() @safety!safetyOn { return Range(data, 0, data.length); } } The application of DIP 1012 would have catastrophic effects on the current tooling but as usual nobody thinks to that.
Re: @safe(bool)
On 17.08.2017 18:36, HyperParrow wrote: On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote: This came to mind while working on a set of containers. [...] One solution could be this: struct Container(T, bool safetyOn = true) { static if(safe) RefCounted!(T[]) data; else T[] data; auto opSlice() @safe(safetyOn) { return Range(data, 0, data.length); } } A similar solution could be applied to @nogc as well. Yeah, i like it more than https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md. That makes little sense to me, as DIP 1012 is strictly more general. template safety(bool safetyOn){ // (this can even be in core) static if(safetyOn) alias safety = FunctionSafety.safe; else alias safety = FunctionSafety.system; // else alias safety = infer!FunctionSafety; // even better! } struct Container(T, bool safetyOn = true){ static if(safe) RefCounted!(T[]) data; else T[] data; auto opSlice() @safety!safetyOn { return Range(data, 0, data.length); } }
Re: @safe(bool)
On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote: The only problem would be the lack of actual @safe annotations on the container, as they would only be applicable to one variant, and otherwise cause a compile-time error. [...] Shouldn't the already compiler derive the appropriate attributes (@safe/@system, @nogc) for functions inside templates?
Re: @safe(bool)
On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote: This came to mind while working on a set of containers. [...] One solution could be this: struct Container(T, bool safetyOn = true) { static if(safe) RefCounted!(T[]) data; else T[] data; auto opSlice() @safe(safetyOn) { return Range(data, 0, data.length); } } A similar solution could be applied to @nogc as well. Yeah, i like it more than https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.
@safe(bool)
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.