Proof of concept - library AA

[IgorStepanov via Digitalmars-d]

On Friday, 29 May 2015 at 22:41:13 UTC, Martin Nowak wrote:
> On Friday, 29 May 2015 at 21:58:16 UTC, IgorStepanov wrote:
>> I suggest you to answer to the following two question:
>> 1. What way to transit to the new AA would be acceptable?
>
> One that doesn't break any code, carefully deprecates necessary 
> semantic changes, and provides an improved implementation.
>
>> You rejects my way (and I could not continue to work in the 
>> winter), and AFAIR you principial objection was: "aaLiteral is 
>> non- at safe for the unsafe code and it is breakage".
>
> The objection was too much code breakage for an inferior 
> implementation.
> https://github.com/D-Programming-Language/druntime/pull/934#issuecomment-66888409
>
>> We may insert additional checks, see aaLiteral attributes, and 
>> raise deprecation message, if attributes are inacceptable.

I recall a list of your demands.

------------------------------------------------------------
1. open addressing
2. efficient construction, insertion and assignment (no extra 
copies or postblits)
3. fully CTFEable (includes storing literals in the data segment)
4. type and attribute correctness
5. get's rid of TypeInfo methods (toHash, opEquals, tsize)
6. GC NO_SCAN for values
------------------------------------------------------------

1. It depends only on library AA implementation, not on 
dmd-druntime interaction.
2. This goal was achieved in my last AA version. Open addressing 
edition may get us troubles with it, but I think this troubles 
are solvable.
3. Storing CTFE literals was implemented in that implementation. 
Maybe not quite right, but the problem is also solvable.
4. This solution follows directly from template implementation.
5. Was done.
6. This problem is also solvable.

Now about backward compatibility:
AFAIR you pointed to the one breakage: the forced checking of 
attribute correctness.
I then entered into an argument with you, but I forgot, that the 
forced  attribute checking was disabled in the last edition:
Yes, aaLiteral gets attributes from the underlying code, and if 
AA constructor was unsafe, aaLiteral was unsafe too.
However, AssocArrayLiteralExp::toElem doesn't check the attribute 
correctness and constructing of unsafe or non-throwable AA from 
safe or throwable code was allowed.
Or I forgot about some other breakage cases?

>> 2. What issues disallows us to implement full library AA? 
>> Except .stringof, .mangleof, and other compiler magic.
>> I see only two issues: opIndexCreate and building aa from 
>> literals.
>
> - error messages
> - attributes
> - literals (especially polysemous initializers, i.e. 
> ubyte[ubyte] aa = [0:1, 1:2])
> - implicit tail const conversion Val[Key] -> const(Val)[Key]
> - lots of magic around making Key const
> - delete aa[key]
> - lots of other small details (grep for Taarray in 
> src/expression.c)
>
> This is a heavily used built-in type, we can't risk a rewrite 
> that breaks lots of code.

>- error messages
Is it a significant problem? If compiler allows correct code, 
disallows incorrect code and gets a clear error messages there 
there is no problem, I think. Of cource, we will need to write 
pretty error messages, implement correct .stringof in dmd (to 
writting type name as V[K], not as AA!(K, V).

> - attributes
We will able to deprecate attribute violations in transitional 
version (with vtbl).

> - literals (especially polysemous initializers, i.e. 
> ubyte[ubyte] aa = [0:1, 1:2])
Yes, this is the first main trouble.

> - implicit tail const conversion Val[Key] -> const(Val)[Key]
May be we may add "alias this"-es for all all those variants?
Something like ...
struct AA(K, V)
{
     alias getCKeyMval this;
     alias getMKeyCval this;
     alias getCKeyCval this;
     @property {
     ref AA!(const(K), V) getCKeyMval() { return 
*cast(typeof(return)*)&this; }
     ref AA!(K, const(V)) getMKeyCval() { return 
*cast(typeof(return)*)&this; }
     ref AA!(const(K), const(V)) getCKeyCval() { return 
*cast(typeof(return)*)&this; }
     }
}

> - lots of magic around making Key const
The most count of them may be solved without language modifying.

> - delete aa[key]
This case has gone one or two years ago.
Now for the following code...
int[int] aa;
delete aa[5];
... compiler writes me "Error: cannot delete type int"

> - lots of other small details (grep for Taarray in 
> src/expression.c)
We should start to try to find and solve them.
As I see, we now we need only two language change requirements: 
opIndexCreate and AA literal overloading.
The rest of the problems can be identified at the stage of 
parallel operation of both implementations.