On Wednesday, 22 October 2014 at 08:14:24 UTC, Ola Fosheim Grøstad wrote:
>
> 2. Easy to write ugly code: It suffers from the same issues as macros.

It is easy to write ugly code in D without string mixins.
Just take a look at the (ab)use of UFCS...

On Wednesday, 22 October 2014 at 12:17:32 UTC, Dejan Lekic wrote:
> It is easy to write ugly code in D without string mixins.
> Just take a look at the (ab)use of UFCS...

I am not a fan of UFCS either… I think it is nice to be able to extend aggregates with new member functions, UFCS isn't required to do that.

I think it would be better to focus on formally defining a nice generic vocabulary of free functions: sort, length etc… and rather add regular pipelining with tuples. E.g.:

arr -> sort -> serialize -> f.write;   ===>   savearray(serialize(sort(arr)))

[(1,2),(3,4)] -> ((_,y1),(x2,_)) => y1*x2 -> f.write;

On Wednesday, 22 October 2014 at 08:44:44 UTC, Ola Fosheim Grøstad wrote:
> On the other hand, C macros can be expanded and then you do source-to-source translation. With D mixins you might have to evaluate CTFE first? That's a source-to-source killer.

If it's fairly complex, like turing-complete, do you think, it will be easier than CTFE?

On Thursday, 23 October 2014 at 11:45:46 UTC, Kagamin wrote:
> On Wednesday, 22 October 2014 at 08:44:44 UTC, Ola Fosheim Grøstad wrote:
>> On the other hand, C macros can be expanded and then you do source-to-source translation. With D mixins you might have to evaluate CTFE first? That's a source-to-source killer.
>
> If it's fairly complex, like turing-complete, do you think, it will be easier than CTFE?

What do you mean by turing-complete in this context?

Both the C preprocessor and D have to terminate in order to produce output… And I see no point in translating programs that cannot be compiled?

Able to perform complex transformations, e.g. D to SQL. Or generate parser from syntax definition, like what pegged does.

On Thursday, 23 October 2014 at 13:54:35 UTC, Kagamin wrote:
> Able to perform complex transformations, e.g. D to SQL. Or generate parser from syntax definition, like what pegged does.

I'm not really sure where you are heading. I am against string mixins, not CTFE.

Ah, ok, I thought, you said CTFE is a source-to-source killer.

Though some refactorings are so simple, they can be done for string mixins too, e.g. https://issues.dlang.org/show_bug.cgi?id=3850

On Wednesday, 22 October 2014 at 07:42:22 UTC, Jonathan M Davis via Digitalmars-d wrote:
> Well, the reality of the matter is that you can't truly clear it safely,
> though we could definitely get closer. The in operator gives pointer access to
> the internals, and the byKey and byValue may do the same (not to mention,
> opApply), and they could be in progress when you try and clear out the AA, so
> if you cleared it out, all of those would still have to work (or maybe throw
> an Error in the cases where iteration is going on).

This is already the case because of .remove(). Adding a clear method wouldn't introduce any *new* problems.

On Friday, October 24, 2014 11:03:11 Jakob Ovrum via Digitalmars-d wrote:
> On Wednesday, 22 October 2014 at 07:42:22 UTC, Jonathan M Davis
>
> via Digitalmars-d wrote:
> > Well, the reality of the matter is that you can't truly clear
> > it safely,
> > though we could definitely get closer. The in operator gives
> > pointer access to
> > the internals, and the byKey and byValue may do the same (not
> > to mention,
> > opApply), and they could be in progress when you try and clear
> > out the AA, so
> > if you cleared it out, all of those would still have to work
> > (or maybe throw
> > an Error in the cases where iteration is going on).
>
> This is already the case because of .remove(). Adding a clear method wouldn't introduce any *new* problems.

True. And I'm certainly not against adding a clear function (quite the opposite in fact). I was just pointingout that it won't work for it to just free all of the memory at that point (that will still be left up to the GC), so it's not like it would magically solve all of the complaints (and the inability to explicitly free the memory seems to be one of the complaints that sparked this thread in the first place). What it _will_ do, however, is make it so that it's possible to affect all references to an AA whereas nulling a reference doesn't do that.

As a side note, it _is_ quite possible to clear out an AA right now; it's just a royal pain and not particularly efficient. All you have to do is use keys() to get an array of the keys, and then iterate over them, removing each one from the AA in turn. And voila, it's been cleared. But it's a pretty ridiculous way to have to go about it. There really should just be a clear function that does it for you (and more efficently, since it probably won't need to allocate an array of the keys to do it and could likely take advantage of internal implementation details to clear it out more efficiently than sequential calls to remove will).

- Jonathan M Davis