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

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

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

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

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.

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?

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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()

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

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

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

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

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:

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

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

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

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 -

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

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

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

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

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,

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

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.

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

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

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

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

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

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

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

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

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[]

@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