Jump to page: 1 24  
Page
Thread overview
June 25
Can you share feature(s) in D people are not talking about which you've found very useful?
June 25
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!
June 26
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


June 25
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
June 26
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
June 26
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.
June 26
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.

June 26
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
June 26
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
June 26
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`.
« First   ‹ Prev
1 2 3 4