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 2017
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 2017
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 2017
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 2017
next sibling 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 2017
next sibling 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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/25/2017 9:31 PM, H. S. Teoh via Digitalmars-d wrote:

 It happens for template functions, member functions of templated
 aggregates (structs/classes), and auto functions.


And all function literals, and all functions generated by the compiler (such as 
lazy delegates and aggregate destructors).
Nov 04 2017
prev sibling parent reply Eljay <eljay.adobe gmail.com> writes:
On Monday, 26 June 2017 at 00:38:21 UTC, Mike wrote:

 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.


If/when D 3.0 happens, as a breaking change, hopefully the 
defaults can be made to be better right defaults.  (D 1.x to D 
2.x had *cough* some breaking changes.)



OCaml that perhaps could be considered for D 3.0.
Nov 04 2017
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 04/11/2017 1:16 PM, Eljay wrote:

 On Monday, 26 June 2017 at 00:38:21 UTC, Mike wrote:

 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.


 
 If/when D 3.0 happens, as a breaking change, hopefully the defaults can 
 be made to be better right defaults.  (D 1.x to D 2.x had *cough* some 
 breaking changes.)
 


 could be considered for D 3.0.


Like signatures which I'm working on!

https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md
Nov 04 2017
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Saturday, 4 November 2017 at 12:20:37 UTC, rikki cattermole 
wrote:

 Like signatures which I'm working on!

 https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md


The first example kind of reminds me of what I was trying to do 
with isSubTypeOf [1]. If you know that any function you can call 
on T can also be called on U, then it has the same effect. That 
being said, I'm not sure I really understand what you mean in the 
whole "Why not extend interfaces" part.


[1] https://github.com/dlang/phobos/pull/5700
Nov 04 2017
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 04/11/2017 2:14 PM, jmh530 wrote:

 On Saturday, 4 November 2017 at 12:20:37 UTC, rikki cattermole wrote:

 Like signatures which I'm working on!

 https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md


 
 The first example kind of reminds me of what I was trying to do with 
 isSubTypeOf [1]. If you know that any function you can call on T can 
 also be called on U, then it has the same effect. That being said, I'm 
 not sure I really understand what you mean in the whole "Why not extend 
 interfaces" part.
 
 
 [1] https://github.com/dlang/phobos/pull/5700


Okay so:

A signature when it is initiated is aware of the implementation it is 
referencing. Allowing it to change how it behaves for compatibility reasons.

An interface is designed so that a class/interface must know of the 
interface to inherit from.

While signatures can and probably will inherit from others, this is not 
how it is used unlike with interfaces. Because this is a massive change 
in how we view them and their usage, extending interfaces is not 
appropriate. Luckily an already existing concept exists in the 
literature which does solve most of the goals and that is signatures 
from the ML family.

I will make a mental note to rewrite that section.
Nov 04 2017
parent reply bauss <jj_1337 live.dk> writes:
On Saturday, 4 November 2017 at 13:27:29 UTC, rikki cattermole 
wrote:

 On 04/11/2017 2:14 PM, jmh530 wrote:

 [...]


 Okay so:

 A signature when it is initiated is aware of the implementation 
 it is referencing. Allowing it to change how it behaves for 
 compatibility reasons.

 An interface is designed so that a class/interface must know of 
 the interface to inherit from.

 While signatures can and probably will inherit from others, 
 this is not how it is used unlike with interfaces. Because this 
 is a massive change in how we view them and their usage, 
 extending interfaces is not appropriate. Luckily an already 
 existing concept exists in the literature which does solve most 
 of the goals and that is signatures from the ML family.

 I will make a mental note to rewrite that section.


It reminds a lot of traits in Rust.

https://doc.rust-lang.org/1.8.0/book/traits.html
Nov 04 2017
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 04/11/2017 6:13 PM, bauss wrote:

 On Saturday, 4 November 2017 at 13:27:29 UTC, rikki cattermole wrote:

 On 04/11/2017 2:14 PM, jmh530 wrote:

 [...]


 Okay so:

 A signature when it is initiated is aware of the implementation it is 
 referencing. Allowing it to change how it behaves for compatibility 
 reasons.

 An interface is designed so that a class/interface must know of the 
 interface to inherit from.

 While signatures can and probably will inherit from others, this is 
 not how it is used unlike with interfaces. Because this is a massive 
 change in how we view them and their usage, extending interfaces is 
 not appropriate. Luckily an already existing concept exists in the 
 literature which does solve most of the goals and that is signatures 
 from the ML family.

 I will make a mental note to rewrite that section.


 
 It reminds a lot of traits in Rust.
 
 https://doc.rust-lang.org/1.8.0/book/traits.html


Rust traits are a variant of ML's signature. Only they decided to add a 
whole new concept which is 'impl' to it.

While it is a nice idea, it would be a pain to use in real life and 
defeat the purpose of a signature. Which is to act as more of a 
'concept' abstraction to other items.

Because we have such powerful meta-programming features I see no reason 
to separate out the two. We can do it all in one which makes it nice and 
consistent between all the different implementations for a signature 
type. So far its starting to feel right at home against our structs and 
class support, I think.
Nov 04 2017
parent Atila Neves <atila.neves gmail.com> writes:
On Sunday, 5 November 2017 at 03:02:52 UTC, rikki cattermole 
wrote:

 On 04/11/2017 6:13 PM, bauss wrote:

 On Saturday, 4 November 2017 at 13:27:29 UTC, rikki cattermole 
 wrote:

 [...]


 
 It reminds a lot of traits in Rust.
 
 https://doc.rust-lang.org/1.8.0/book/traits.html


 Rust traits are a variant of ML's signature. Only they decided 
 to add a whole new concept which is 'impl' to it.

 While it is a nice idea, it would be a pain to use in real life 
 and defeat the purpose of a signature. Which is to act as more 
 of a 'concept' abstraction to other items.

 Because we have such powerful meta-programming features I see 
 no reason to separate out the two. We can do it all in one 
 which makes it nice and consistent between all the different 
 implementations for a signature type. So far its starting to 
 feel right at home against our structs and class support, I 
 think.


I like Rust's traits more than our way of ad-hoc specification of 
compile-time interfaces with is(typeof({...})) or 
__traits(compiles, ...). Given how most idiomatic D code is 
written, to me that's the biggest deficiency of the language. 
Reasonable people may, of course, disagree.

Atila
Nov 06 2017
prev sibling next 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 2017
prev sibling next sibling parent codephantom <me noyb.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?


How about the compiler option: -release

then I don't have to care about your god damn contract anymore.

;-)
Nov 05 2017
prev sibling next sibling parent user1234 <user1234 12.12> 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 see none.

¯\_(ツ)_/¯

Everything is more or less discussed and known. I was not 
surprised when i saw that the topic went OT since (almost) the 
beginning.
Nov 07 2017
prev sibling next sibling parent reply Gary Willoughby <dev nomad.so> 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?


Some of the best features are in the standard library. I've 
written about them here:

http://nomad.so/2014/08/hidden-treasure-in-the-d-standard-library/
http://nomad.so/2015/08/more-hidden-treasure-in-the-d-standard-library/
Nov 07 2017
parent Jon Degenhardt <jond noreply.com> writes:
On Tuesday, 7 November 2017 at 17:15:02 UTC, Gary Willoughby 
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?


 Some of the best features are in the standard library. I've 
 written about them here:

 http://nomad.so/2014/08/hidden-treasure-in-the-d-standard-library/
 http://nomad.so/2015/08/more-hidden-treasure-in-the-d-standard-library/


It's mentioned in Gary's articles, but std.conv.to is fantastic.
Nov 07 2017
prev sibling parent reply codephantom <me noyb.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?


How about this feature: i.e. it actually compiles just fine ;-)

//------------------------------------------------------------

module test;

void main()
{
     void main()
     {
         void main()
         {
             void main()
             {
                 void main()
                 {
                     void main()
                     {
                         void main()
                         {
                             //and so on... and so on....and so 
on....
                         }
                     }
                 }
             }

         }
     }
}

//------------------------------------------------------------
Nov 07 2017
parent bauss <jj_1337 live.dk> writes:
On Wednesday, 8 November 2017 at 01:24:57 UTC, codephantom 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?


 How about this feature: i.e. it actually compiles just fine ;-)

 //------------------------------------------------------------

 module test;

 void main()
 {
     void main()
     {
         void main()
         {
             void main()
             {
                 void main()
                 {
                     void main()
                     {
                         void main()
                         {
                             //and so on... and so on....and so 
 on....
                         }
                     }
                 }
             }

         }
     }
 }

 //------------------------------------------------------------


I laughed.

At it's even funnier when you realize that there's actually 
generated assembly code for the nested main functions:

```
void test.main().main():
  push   %rbp
  mov    %rsp,%rbp
  sub    $0x10,%rsp
  mov    %rdi,-0x8(%rbp)
  leaveq
  retq
  xchg   %ax,%ax
```

However as you can see it only generates for one of the nested 
functions, the rest are omitted.

You can never call the function though :p
Nov 07 2017