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.

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

I also hope that for D 3.0, both Walter and Andrei play with F# or OCaml for a while.  There's a lot of Good Things in F# and OCaml that perhaps could be considered for D 3.0.

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.)
> 
> I also hope that for D 3.0, both Walter and Andrei play with F# or OCaml for a while.  There's a lot of Good Things in F# and OCaml that perhaps 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

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

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.

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

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

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.

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.

;-)

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