On Friday, 31 July 2015 at 04:47:20 UTC, Enamex wrote:
> Right now docs say that `delete` is getting deprecated but using it on DMD .067.1 gives no warnings.

There are no warnings because it hasn't actually been deprecated yet. So, the docs are quite correct. They say that it's _going_ to be deprecated, not that it has been deprecated. Ideally, it would have been deprecated quite some time ago, but without the custom allocators, it's a lot harder to do something similar to what delete does. So, if we'd actually deprecated it, we'd have done so without a viable alternative (it's possible without custom allocators, but it's hard to get right). Now, I think that the reality of the matter that it hasn't been deprecated is simply because no one has gotten around to it yet, but there are problems with deprecating it prior getting customer allocators. Fortunately, it looks like we will soon have that in std.experimental, so it will become more reasonable to deprecate delete, and maybe we can finally deprecate it and start moving it out of the language. But it's been planned for ages that delete would be removed from D at some point.

- Jonathan M Davis

On Friday, 31 July 2015 at 09:37:10 UTC, Jonathan M Davis wrote:
> On Friday, 31 July 2015 at 04:47:20 UTC, Enamex wrote:
>> Right now docs say that `delete` is getting deprecated but using it on DMD .067.1 gives no warnings.
>
> There are no warnings because it hasn't actually been deprecated yet. So, the docs are quite correct. They say that it's _going_ to be deprecated, not that it has been deprecated. Ideally, it would have been deprecated quite some time ago, but without the custom allocators, it's a lot harder to do something similar to what delete does. So, if we'd actually deprecated it, we'd have done so without a viable alternative (it's possible without custom allocators, but it's hard to get right). Now, I think that the reality of the matter that it hasn't been deprecated is simply because no one has gotten around to it yet, but there are problems with deprecating it prior getting customer allocators. Fortunately, it looks like we will soon have that in std.experimental, so it will become more reasonable to deprecate delete, and maybe we can finally deprecate it and start moving it out of the language. But it's been planned for ages that delete would be removed from D at some point.
>
> - Jonathan M Davis

I would much rather delete to stay and rig it up so new and delete call the global allocator(which would be the GC by default).

On Sunday, 26 July 2015 at 23:29:18 UTC, Walter Bright wrote:

> For example, the '+' operator. Rust traits sez "gee, there's a + operator, it's good to go. Ship it!" Meanwhile, you thought the function was summing some data, when it actually is creating a giant string, or whatever idiot thing someone decided to use '+' for.

Number addition and string concatenation are monoid operations. In this light, '+' for both makes perfect sense.

On Sunday, 2 August 2015 at 19:02:22 UTC, Max Samukha wrote:
> On Sunday, 26 July 2015 at 23:29:18 UTC, Walter Bright wrote:
>
>> For example, the '+' operator. Rust traits sez "gee, there's a + operator, it's good to go. Ship it!" Meanwhile, you thought the function was summing some data, when it actually is creating a giant string, or whatever idiot thing someone decided to use '+' for.
>
> Number addition and string concatenation are monoid operations. In this light, '+' for both makes perfect sense.

Well, using + for "adding" strings together does make sense on some level, which is why it's done in so many languages, and I don't think that it causes as much confusion as Walter sometimes seems to think (at least in C/C++-derived languages). That being said, I think that it's definitely an improvement that D has another operator for it. It makes it clearer when concatenation is occurring without having to figure out what types you're dealing with, and it allows user-defined code to have both an addition operator and a concatenation operator on the same type.

Where distinguishing between + and ~ would likely make a big difference though is dynamic languages that aren't strict with types and allow nonsense like "5" + 2. And in that case, I expect that Walter is completely right. It's just error-prone to use + for concatenation in cases like that, and providing a separate concatenation operator would reduce bugs.

Regardless, I definitely like the fact that we have ~ and ~= instead of reusing + and += for that. It's a small improvement, but it is an improvement.

- Jonathan M Davis

On Sunday, 2 August 2015 at 21:17:10 UTC, Jonathan M Davis wrote:
> types you're dealing with, and it allows user-defined code to have both an addition operator and a concatenation operator on the same type.

I assume you mean vectors, though I would prefer binary "++" for that.

> Where distinguishing between + and ~ would likely make a big difference though is dynamic languages that aren't strict with types and allow nonsense like "5" + 2. And in that case, I expect that Walter is completely right. It's just error-prone to use + for concatenation in cases like that, and providing a separate concatenation operator would reduce bugs.

I've never run into such bugs, have you? The ambigious case
would be "result:" + 3 + 8 , but you can solve this by giving numeric plus higher precedence or avoid implicit conversion. Though, these days it is more common to support something like "result: {{3+8}}".

> Regardless, I definitely like the fact that we have ~ and ~= instead of reusing + and += for that. It's a small improvement, but it is an improvement.

It's a weird thing to do for a C-decendant as I would expect "~=" to do binary negation.

On 08/02/2015 09:02 PM, Max Samukha wrote:
> On Sunday, 26 July 2015 at 23:29:18 UTC, Walter Bright wrote:
>
>> For example, the '+' operator. Rust traits sez "gee, there's a +
>> operator, it's good to go. Ship it!" Meanwhile, you thought the
>> function was summing some data, when it actually is creating a giant
>> string, or whatever idiot thing someone decided to use '+' for.
>
> Number addition and string concatenation are monoid operations. In this
> light, '+' for both makes perfect sense.

'+' is usually used to denote the operation of an abelian group.

On Friday, 31 July 2015 at 09:37:10 UTC, Jonathan M Davis wrote:
> On Friday, 31 July 2015 at 04:47:20 UTC, Enamex wrote:
>> Right now docs say that `delete` is getting deprecated but using it on DMD .067.1 gives no warnings.
>
> There are no warnings because it hasn't actually been deprecated yet.
> [...]
> - Jonathan M Davis

GC and memory management in general are inadequately documented. There're doc-pages and answers on SO and discussions on the forum about stuff that (coming from C++) should be so basic, like how to allocate an instance of a struct on the heap (GC'ed or otherwise) or how to allocate a class on non-managed heap (still don't get how `Unique!` works; does it even register with the GC? How to deep-copy/not-move its contents into another variable?), or on the stack, for that matter (there's `scoped!` but docs again are confusing. It's somehow stack-allocated but can't be copied?).

Eventually deprecating it while leaving it now without any warnings (though the docs warn; offer no replacement) seems like it'd be more trouble than it's worth down the line, since it's not a feature addition or even full deprecation but -AFAIU- a replacement of semantics for identical syntax.

On Monday, 3 August 2015 at 06:52:41 UTC, Timon Gehr wrote:
> On 08/02/2015 09:02 PM, Max Samukha wrote:
>> On Sunday, 26 July 2015 at 23:29:18 UTC, Walter Bright wrote:
>>
>>> For example, the '+' operator. Rust traits sez "gee, there's a +
>>> operator, it's good to go. Ship it!" Meanwhile, you thought the
>>> function was summing some data, when it actually is creating a giant
>>> string, or whatever idiot thing someone decided to use '+' for.
>>
>> Number addition and string concatenation are monoid operations. In this
>> light, '+' for both makes perfect sense.
>
> '+' is usually used to denote the operation of an abelian group.

The point is that '+' for string concatenation is no more of an 'idiot thing' than '~'.

On Sunday, 2 August 2015 at 21:17:10 UTC, Jonathan M Davis wrote:
> Where distinguishing between + and ~ would likely make a big difference though is dynamic languages that aren't strict with types and allow nonsense like "5" + 2.

Using '~' instead of '+' to concatenate strings is just a syntax and says nothing about type system.

On Saturday, 25 July 2015 at 08:58:26 UTC, Walter Bright wrote:
> I would have had a LOT more trouble shipping the Warp project if I hadn't gone with 100% coverage from the ground up. Nearly all the bugs it had in the field were due to my misunderstandings of the peculiarities of gpp - the code had worked as I designed it.
>
> This is a huge reason why I want to switch to ddmd. I want to improve the quality of the compiler with unit tests. The various unit tests schemes I've tried for C++ are all ugly, inconvenient, and simply a bitch. It's like trying to use a slide rule after you've been given a calculator.

LOL. I finally got some bugs sorted out on the project that I'm working on at work (in C++), which means that I can get back to what I was working on implementing before, and about all I recall for sure is that I was working on the unit tests for it. I don't know where I was with them. I find myself wishing that I had -cov so that I could figure out what I had left to test... :(

It often seems like the advantages of some of D's features are more obvious when you have to go back to another language like C++ which doesn't have them.

- Jonathan M Davis