www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What are the unused but useful feature you know in D?

reply aberba <karabutaworld gmail.com> writes:
Can you share feature(s) in D people are not talking about which 
you've found very useful?
Jun 25
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 25 June 2017 at 23:21:25 UTC, aberba wrote:
 Can you share feature(s) in D people are not talking about 
 which you've found very useful?
I actually like anonymous classes. D took it from Java and D has a lot of other ways to do it too, but I've found anonymous classes to be nice with using my gui lib... and the only time I see other people talk about them is wanting to remove them from the language!
Jun 25
parent Jacob Carlborg <doob me.com> writes:
On 2017-06-26 01:24, Adam D. Ruppe wrote:

 I actually like anonymous classes. D took it from Java and D has a lot
 of other ways to do it too, but I've found anonymous classes to be nice
 with using my gui lib... and the only time I see other people talk about
 them is wanting to remove them from the language!
They're used heavily in DWT [1], since it's ported from Java. Before Java 8, when lambdas was introduced, anonymous classes inheriting from some interface is what was used to handle events. [1] https://github.com/d-widget-toolkit/dwt -- /Jacob Carlborg
Jun 26
prev sibling next sibling parent reply Mike <none none.com> writes:
On Sunday, 25 June 2017 at 23:21:25 UTC, aberba wrote:
 Can you share feature(s) in D people are not talking about 
 which you've found very useful?
In my experience, using appropriate attributes for functions, variables, etc... doesn't happen like it should. This includes attributes like ` safe`, `immutable`, `pure`, `const`, and others. I recently watched of video where Andrei acknowledged this when talking about the `pure` attribute (https://youtu.be/WsgW4HJXEAg?t=3052). It was also acknowledged somewhat by Walter in his talk at DConf 2017 (https://youtu.be/iDFhvCkCLb4?t=2531). As I understand it, though, the D compiler has some logic to automatically infer some of these attributes, but because its *invisible* to the user it's difficult to predict what those inferences are, and there's no documentation that I'm aware of that defines how/where/where this happens. IMO, part of the problem is that D has the wrong defaults (e.g. `immutable` by default, ` safe` by default, `final` by default, etc...), so users have to opt in to these things when they should really only be opting out of them. Unfortunately, changing this would be disruptive and will probably never happen without a fork. Mike
Jun 25
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Jun 26, 2017 at 12:38:21AM +0000, Mike via Digitalmars-d wrote:
 On Sunday, 25 June 2017 at 23:21:25 UTC, aberba wrote:
 Can you share feature(s) in D people are not talking about which
 you've found very useful?
In my experience, using appropriate attributes for functions, variables, etc... doesn't happen like it should. This includes attributes like ` safe`, `immutable`, `pure`, `const`, and others. I recently watched of video where Andrei acknowledged this when talking about the `pure` attribute (https://youtu.be/WsgW4HJXEAg?t=3052). It was also acknowledged somewhat by Walter in his talk at DConf 2017 (https://youtu.be/iDFhvCkCLb4?t=2531). As I understand it, though, the D compiler has some logic to automatically infer some of these attributes, but because its *invisible* to the user it's difficult to predict what those inferences are, and there's no documentation that I'm aware of that defines how/where/where this happens.
It happens for template functions, member functions of templated aggregates (structs/classes), and auto functions. One of the reasons it's undocumented or underdocumented is because it's a moving target: the goal is to apply automatic inference as widely as possible. Requiring users to manually write attributes is ultimately an impractical plan, especially when the number of attributes increase. You can always use pragma(msg, typeof(...)) to find out exactly what was inferred. To ensure that a particular template function *must* have some attribute as long as none of its arguments break it, use an attributed unittest. E.g.: auto myTemplateFunc(Range)(Range r) if (isInputRange!Range) { } pure unittest { auto r = [1,2,3].myTemplateFunc(); } The reason you don't want to stick the attribute on the function itself is because then it will preclude using it with a range that happens to have impure methods, whereas what you want is that the function is pure if the range is also pure, but if the range is impure, it's OK for the function to be impure. This is achieved by putting the attribute on the unittest: since [1,2,3] is a range known to be pure, any source of impurity must have come from the function; the pure attribute on the unittest would force a compile error in that case.
 IMO, part of the problem is that D has the wrong defaults (e.g.
 `immutable` by default, ` safe` by default, `final` by default,
 etc...), so users have to opt in to these things when they should
 really only be opting out of them.  Unfortunately, changing this would
 be disruptive and will probably never happen without a fork.
[...] Yes, the wrong defaults were a historical accident. It was inherited from before D had attributes, so when the attributes were added, the only way was to add attributes that negate the status quo rather than change the default setting, otherwise it would have completely broken everyone's code. Pretty much everyone here agrees that if we could start over, we would have pure by default, nothrow by default, safe by default, etc., and only require marking when something is impure, throwing, system, etc.. But as they say, hindsight is always 20/20... it was not obvious back when D was first designed. T -- Only boring people get bored. -- JM
Jun 25
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 26 June 2017 at 04:31:33 UTC, H. S. Teoh wrote:
 Yes, the wrong defaults were a historical accident.
One that we could fix, even without breaking any code. Of course, breaking some code to change it would be fairly straightforward to fix for authors, and could even be done automatically in theory (something like dfix), but there's another solution too: opt in once per module, then change things. Javascript did this to pretty good success with its "use strict" thing. --- // status quo D module foo.bar; safe void whatever() {} --- --- // next gen D module version(3.0) foo.bar; // opt in here void whatever() {} // now safe by default --- The syntax could be whatever, but inside the compiler, when it detects that, it switches around the default for the module. Being opt in means only maintained files get it, but being single point change means it is easy to do. And since changes like this can easily live side by side with other modules, it provides a simple path forward. So here's how I'd do it: 1) Add the opposite attributes: `impure`, `throws`, ` gc`, etc. 2) Add the module version thing that changes defaults on request 3) imagine more potential going forward It isn't even hard.
Jun 26
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 26 June 2017 at 14:17:26 UTC, Adam D. Ruppe wrote:

 So here's how I'd do it:

 1) Add the opposite attributes: `impure`, `throws`, ` gc`, etc.
 2) Add the module version thing that changes defaults on request
 3) imagine more potential going forward


 It isn't even hard.
And along with that a compiler switch to enable strict mode by default. If you, or anyone else, is willing to put this in DIP form, I'll gladly do what I can to help minimize the effort required to write it up. This is something I'd love to see.
Jun 26
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Jun 26, 2017 at 02:39:30PM +0000, Mike Parker via Digitalmars-d wrote:
 On Monday, 26 June 2017 at 14:17:26 UTC, Adam D. Ruppe wrote:
 
 
 So here's how I'd do it:
 
 1) Add the opposite attributes: `impure`, `throws`, ` gc`, etc.
 2) Add the module version thing that changes defaults on request
 3) imagine more potential going forward
 
 
 It isn't even hard.
And along with that a compiler switch to enable strict mode by default. If you, or anyone else, is willing to put this in DIP form, I'll gladly do what I can to help minimize the effort required to write it up. This is something I'd love to see.
Yes, please do! If we can push this through, D could be in a much, much better place in a few years' time! Actually, couldn't we use the same versioning mechanism for *most* of the proposed changes that are currently turned down because they would break too much code? Using this versioning would allow us to introduce breaking changes in an opt-in way, thus allowing codebases the needed time to migrate. T -- MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
Jun 26
next sibling parent Seb <seb wilzba.ch> writes:
On Monday, 26 June 2017 at 16:10:01 UTC, H. S. Teoh wrote:
 On Mon, Jun 26, 2017 at 02:39:30PM +0000, Mike Parker via 
 Digitalmars-d wrote:
 On Monday, 26 June 2017 at 14:17:26 UTC, Adam D. Ruppe wrote:
 
 
 So here's how I'd do it:
 
 1) Add the opposite attributes: `impure`, `throws`, ` gc`, 
 etc. 2) Add the module version thing that changes defaults 
 on request 3) imagine more potential going forward
 
 
 It isn't even hard.
And along with that a compiler switch to enable strict mode by default. If you, or anyone else, is willing to put this in DIP form, I'll gladly do what I can to help minimize the effort required to write it up. This is something I'd love to see.
Yes, please do! If we can push this through, D could be in a much, much better place in a few years' time! Actually, couldn't we use the same versioning mechanism for *most* of the proposed changes that are currently turned down because they would break too much code? Using this versioning would allow us to introduce breaking changes in an opt-in way, thus allowing codebases the needed time to migrate.
This idea is brillant! We could use it to finally get rid off auto-decoding - a small PoC: https://github.com/dlang/phobos/pull/5513
Jun 26
prev sibling parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Monday, 26 June 2017 at 16:10:01 UTC, H. S. Teoh wrote:
 On Mon, Jun 26, 2017 at 02:39:30PM +0000, Mike Parker via 
 Digitalmars-d wrote:
 On Monday, 26 June 2017 at 14:17:26 UTC, Adam D. Ruppe wrote:
 
 
 So here's how I'd do it:
 
 1) Add the opposite attributes: `impure`, `throws`, ` gc`, 
 etc. 2) Add the module version thing that changes defaults 
 on request 3) imagine more potential going forward
 
 
 It isn't even hard.
And along with that a compiler switch to enable strict mode by default. If you, or anyone else, is willing to put this in DIP form, I'll gladly do what I can to help minimize the effort required to write it up. This is something I'd love to see.
Yes, please do! If we can push this through, D could be in a much, much better place in a few years' time!
As long as you don't introduce immutable by default, resulting in datastructures being littered with `mutable`.
Jun 26
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 26 June 2017 at 16:51:06 UTC, Moritz Maxeiner wrote:
 As long as you don't introduce immutable by default, resulting 
 in datastructures being littered with `mutable`.
Yeah, I'm against immutable by default. Also, my nogc, safe, etc by default idea does NOT apply to main() or virtual methods. I have explained why before and feel like we are hijacking this thread now though....
Jun 26
prev sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
On Monday, 26 June 2017 at 16:51:06 UTC, Moritz Maxeiner wrote:
 On Monday, 26 June 2017 at 16:10:01 UTC, H. S. Teoh wrote:
 Yes, please do!  If we can push this through, D could be in a 
 much, much better place in a few years' time!
As long as you don't introduce immutable by default, resulting in datastructures being littered with `mutable`.
Addendum: I'm also not in favor of `nothrow` by default, because imho that contradicts D's error handling using exceptions by default.
Jun 26
prev sibling next sibling parent reply Random D user <no email.com> writes:
On Monday, 26 June 2017 at 14:17:26 UTC, Adam D. Ruppe wrote:
 1) Add the opposite attributes: `impure`, `throws`, ` gc`, etc.
 2) Add the module version thing that changes defaults on request
 3) imagine more potential going forward
I dislike doubling the keywords by having a 'not' case for each. I'd rather have a systematic way of adding/removing attributes and udas. Something like: gc !gc (previously nogc, compiler could even rewrite nogc into !gc for transition) --- Anyway, I think we could just have a compile time switch for defaults. Since some projects want to have pure, safe, immutable by default, but others want to have system nogc. And no one wants write attributes more than they have to. For example, I kind of like the current defaults since I like flexibility/changeability/editability of code. Because that makes coding fun which in turn usually means better code, features and productivity. Strictness is just a kind of salt that can be sprinkled on code in few difficult or dangerous cases. Also I think safe is a little bit broken (because of trusted and even the very pros (d-devs) seem to get trusted wrong on a regular basis (at least that's my perception)). Just bite the bullet and use Rust if you want to be actually safe. I'm not a huge fan of immutable/const system either as it's kind of difficult to use and low benefits. It often leads into backtracking and changing your code all over the place (small change becomes an avalanche), because you found out in the last leaf function of your subsystem, that your design can't actually be immutable (basically, you forgot or couldn't imagine that elusive corner case no. 99). The good thing is that immutable/const is actually strict and checkable. No holes like in safe. So if this change would happen, I would probably start all of my d files with impure: system: ( nogc:) // depending on my needs, I actually haven't had big issues with the gc (nothrow:) ... Which reminds me that it would be nice to group attributes as well. Something like this: alias apiStrict = safe immutable pure int foo() apiStrict { return 1; }
Jun 26
next sibling parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Monday, 26 June 2017 at 18:47:18 UTC, Random D user wrote:
 Anyway, I think we could just have a compile time switch for 
 defaults.
Imagine having n libraries with pairwise different required defaults used in your application. Say goodbye to combined compilation, hello n separate required compiler invocations.
 Since some projects want to have pure,  safe, immutable by 
 default, but others want to have  system  nogc. And no one 
 wants write attributes more than they have to.
That's why most of what I do is in templates, so the compiler infers them for me, anyway.
 Also I think  safe is a little bit broken (because of  trusted 
 and even the very pros (d-devs) seem to get  trusted wrong on a 
 regular basis (at least that's my perception)). Just bite the 
 bullet and use Rust if you want to be actually safe.
Except Rust is in exactly the same boat as D, because the same issues that apply to ` trusted` apply to `unsafe`, as well.
 Which reminds me that it would be nice to group attributes as 
 well.
 Something like this:
 alias  apiStrict =  safe immutable pure

 int foo()  apiStrict
 {
   return 1;
 }
That would be useful.
Jun 26
parent reply Random D user <no email.com> writes:
On Monday, 26 June 2017 at 22:17:00 UTC, Moritz Maxeiner wrote:
 On Monday, 26 June 2017 at 18:47:18 UTC, Random D user wrote:
 Anyway, I think we could just have a compile time switch for 
 defaults.
Imagine having n libraries with pairwise different required defaults used in your application. Say goodbye to combined compilation, hello n separate required compiler invocations.
Yeah, that's true. I didn't really think of full source compilation of libs in your project. I though .lib would've been compiled with some settings and you'd just link with that and work with its api. Also in reality I wouldn't want to be able to cancel nogc in a function, because then the attribute would just lose power and you couldn't trust it. I just used it as a simple example for the and ! syntax that I'd like to have in general. Which would allow a nice way of working with sections of code like this: class { nogc: or !gc: ... some code .. gc: or gc: ... more code .. nogc: or !gc: ... even more code .. }
 Also I think  safe is a little bit broken (because of  trusted 
 and even the very pros (d-devs) seem to get  trusted wrong on 
 a regular basis (at least that's my perception)). Just bite 
 the bullet and use Rust if you want to be actually safe.
Except Rust is in exactly the same boat as D, because the same issues that apply to ` trusted` apply to `unsafe`, as well.
Hmmm, I guess that's true. I don't really know a lot about Rust. Their safety story just sounds way more convincing and believable than D's. It would probably be the first language I'd look into if I was interested in low level safety critical code.
Jun 27
parent Moritz Maxeiner <moritz ucworks.org> writes:
On Tuesday, 27 June 2017 at 19:06:19 UTC, Random D user wrote:
 On Monday, 26 June 2017 at 22:17:00 UTC, Moritz Maxeiner wrote:
 Except Rust is in exactly the same boat as D, because the same 
 issues that apply to ` trusted` apply to `unsafe`, as well.
Hmmm, I guess that's true. I don't really know a lot about Rust. Their safety story just sounds way more convincing and believable than D's. It would probably be the first language I'd look into if I was interested in low level safety critical code.
The power of having plenty of money to pay for (viral) marketing. Or in short: Propaganda. Rust is a good PL, but in practice it isn't significantly safer than safe D in my experience. And you pay for that small difference dearly with productivity decrease (even after becoming comfortable with the borrow checker system).
Jun 27
prev sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Monday, 26 June 2017 at 18:47:18 UTC, Random D user wrote:
 On Monday, 26 June 2017 at 14:17:26 UTC, Adam D. Ruppe wrote:
 1) Add the opposite attributes: `impure`, `throws`, ` gc`, etc.
 2) Add the module version thing that changes defaults on 
 request
 3) imagine more potential going forward
I dislike doubling the keywords by having a 'not' case for each. I'd rather have a systematic way of adding/removing attributes and udas. Something like: gc !gc (previously nogc, compiler could even rewrite nogc into !gc for transition) --- Anyway, I think we could just have a compile time switch for defaults. Since some projects want to have pure, safe, immutable by default, but others want to have system nogc. And no one wants write attributes more than they have to. For example, I kind of like the current defaults since I like flexibility/changeability/editability of code. Because that makes coding fun which in turn usually means better code, features and productivity. Strictness is just a kind of salt that can be sprinkled on code in few difficult or dangerous cases. Also I think safe is a little bit broken (because of trusted and even the very pros (d-devs) seem to get trusted wrong on a regular basis (at least that's my perception)). Just bite the bullet and use Rust if you want to be actually safe. I'm not a huge fan of immutable/const system either as it's kind of difficult to use and low benefits. It often leads into backtracking and changing your code all over the place (small change becomes an avalanche), because you found out in the last leaf function of your subsystem, that your design can't actually be immutable (basically, you forgot or couldn't imagine that elusive corner case no. 99). The good thing is that immutable/const is actually strict and checkable. No holes like in safe. So if this change would happen, I would probably start all of my d files with impure: system: ( nogc:) // depending on my needs, I actually haven't had big issues with the gc (nothrow:) ... Which reminds me that it would be nice to group attributes as well. Something like this: alias apiStrict = safe immutable pure int foo() apiStrict { return 1; }
Hmm I really like this. If we could have an AttributeAliasSeq then we could solve all of the inversion problems by simply removing them from the list. This would also allow us to define a default set of attributes (in say core.attribute) that every symbol (except templates?) get tagged by. Then you could change the default set of attributes by a version switch. Or we could have the default attribute set apply to the module (declaration?) and be user overridable and then any explicit attributes applied to symbols override the default module attributes. I think I'll write a DIP for this after my honours thesis.
Jun 26
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 27 June 2017 at 02:19:56 UTC, Nicholas Wilson wrote:
 I think I'll write a DIP for this after my honours thesis.
Initial draft https://github.com/thewilsonator/DIPs/blob/Attributes/DIPs/DIPxxxx_attributes.md Don't expect much from me until 4th of July.
Jun 26
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 27 June 2017 at 03:14:58 UTC, Nicholas Wilson wrote:
 On Tuesday, 27 June 2017 at 02:19:56 UTC, Nicholas Wilson wrote:
 I think I'll write a DIP for this after my honours thesis.
Initial draft https://github.com/thewilsonator/DIPs/blob/Attributes/DIPs/DIPxxxx_attributes.md Don't expect much from me until 4th of July.
https://github.com/dlang/DIPs/pull/75
Jul 03
prev sibling parent Mike <none none.com> writes:
On Monday, 26 June 2017 at 14:17:26 UTC, Adam D. Ruppe wrote:

 // next gen D
 module version(3.0) foo.bar; // opt in here
 void whatever() {} // now  safe by default
That's a really good idea.
Jun 26
prev sibling parent solidstate1991 <laszloszeremi outlook.com> writes:
On Sunday, 25 June 2017 at 23:21:25 UTC, aberba wrote:
 Can you share feature(s) in D people are not talking about 
 which you've found very useful?
If you need to write a lightweight library or app with no GC and Phobos, you can fall back to C functions in core.stdc, my wavefile codec/utility (ADPCM, interpolation, resampling, etc.) is being written this way.
Jul 03