We're entering the finale of D2 and I want to keep a short list of things that must be done and integrated in the release. It is clearly understood by all of us that there are many things that could and probably should be done.

1. Currently Walter and Don are diligently fixing the problems marked on the current manuscript.

2. User-defined operators must be revamped. Fortunately Don already put in an important piece of functionality (opDollar). What we're looking at is a two-pronged attack motivated by Don's proposal:

http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7

The two prongs are:

* Encode operators by compile-time strings. For example, instead of the plethora of opAdd, opMul, ..., we'd have this:

T opBinary(string op)(T rhs) { ... }

The string is "+", "*", etc. We need to design what happens with read-modify-write operators like "+=" (should they be dispatch to a different function? etc.) and also what happens with index-and-modify operators like "[]=", "[]+=" etc. Should we go with proxies? Absorb them in opBinary? Define another dedicated method? etc.

* Loop fusion that generalizes array-wise operations. This idea of Walter is, I think, very good because it generalizes and democratizes "magic". The idea is that, if you do

a = b + c;

and b + c does not make sense but b and c are ranges for which a.front = b.front + c.front does make sense, to automatically add the iteration paraphernalia.

3. It was mentioned in this group that if getopt() does not work in SafeD, then SafeD may as well pack and go home. I agree. We need to make it work. Three ideas discussed with Walter:

* Allow taking addresses of locals, but in that case switch allocation from stack to heap, just like with delegates. If we only do that in SafeD, behavior will be different than with regular D. In any case, it's an inefficient proposition, particularly for getopt() which actually does not need to escape the addresses - just fills them up.

* Allow @trusted (and maybe even @safe) functions to receive addresses of locals. Statically check that they never escape an address of a parameter. I think this is very interesting because it enlarges the common ground of D and SafeD.

* Figure out a way to reconcile "ref" with variadics. This is the actual reason why getopt chose to traffic in addresses, and fixing it is the logical choice and my personal favorite.

4. Allow private members inside a template using the eponymous trick:

template wyda(int x) {
   private enum geeba = x / 2;
   alias geeba wyda;
}

The names inside an eponymous template are only accessible to the current instantiation. For example, wyda!5 cannot access wyda!(4).geeba, only its own geeba. That we we elegantly avoid the issue "where is this symbol looked up?"

5. Chain exceptions instead of having a recurrent exception terminate the program. I'll dedicate a separate post to this.

6. There must be many things I forgot to mention, or that cause grief to many of us. Please add to/comment on this list.



Andrei

What about the business with signed/unsigned integer comparisons?

Andrei Alexandrescu:

> * Encode operators by compile-time strings. For example, instead of the plethora of opAdd, opMul, ..., we'd have this:
> 
> T opBinary(string op)(T rhs) { ... }
> 
> The string is "+", "*", etc.

Can you show an example of defining an operator, like a minus, with that?

In my set data structure I'd like to define "<=" among two sets as "is subset". Can that design allow me to overload just <= and >= ? (opCmp is not enough here).

Bye,
bearophile

Ellery Newcomer wrote:
> What about the business with signed/unsigned integer comparisons?

I think that's somewhere in the TDPL non-working snippets, but I added your message to my worklist to make sure.

Andrei

bearophile wrote:
> Andrei Alexandrescu:
> 
>> * Encode operators by compile-time strings. For example, instead of
>> the plethora of opAdd, opMul, ..., we'd have this:
>> 
>> T opBinary(string op)(T rhs) { ... }
>> 
>> The string is "+", "*", etc.
> 
> Can you show an example of defining an operator, like a minus, with
> that?

struct BigInt {
   BigInt opBinary(string op)(BigInt rhs) if (op == "-") {
      ...
   }
}

> In my set data structure I'd like to define "<=" among two sets as
> "is subset". Can that design allow me to overload just <= and >= ?
> (opCmp is not enough here).

It could if we decide to deprecate opCmp. I happen to like it; if you define a <= b for inclusion, people will think it's natural to also allow a < b for strict inclusion. But that's up for debate.

I'm not sure what the best way is. Classes have opEquals and opCmp so the question is - do we want structs to be somewhat compatible with classes or not? My personal favorite choice would be to go full bore with compile-time strings.


Andrei

bearophile wrote:
> Andrei Alexandrescu:
> 
>> * Encode operators by compile-time strings. For example, instead of the plethora of opAdd, opMul, ..., we'd have this:
>>
>> T opBinary(string op)(T rhs) { ... }
>>
>> The string is "+", "*", etc.
> 
> Can you show an example of defining an operator, like a minus, with that?
>

T opBinary(string op)(T rhs) {
	static if (op == "-") return data - rhs.data;
	static if (op == "+") return data + rhs.data;

	// ... maybe this would work too ...
	mixin("return data " ~ op ~ "rhs.data;");
}

I love this syntax over the tons of different operation functions. Makes it so much nicer, especially when supporting a bunch of different paramater types (vectors are a good example of this).

T opBinary(string op)(T rhs)
T opBinary(string op)(float[3] rhs)
T opBinary(string op)(float rx, ry, rz)
....

> In my set data structure I'd like to define "<=" among two sets as "is subset". Can that design allow me to overload just <= and >= ? (opCmp is not enough here).
> 
> Bye,
> bearophile

Andrei Alexandrescu Wrote:

> 6. There must be many things I forgot to mention, or that cause grief to many of us. Please add to/comment on this list.
> 
> Andrei

Well, there is this page on Wiki4D

http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections

which has what the community is trying to track for changes. It also has some things that haven't got officially declined committed to.

Andrei Alexandrescu wrote:
> Ellery Newcomer wrote:
>> What about the business with signed/unsigned integer comparisons?
> 
> I think that's somewhere in the TDPL non-working snippets, but I added your message to my worklist to make sure.
> 
> Andrei

Cool, thanks

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s
article
> 6. There must be many things I forgot to mention, or that cause
grief to
> many of us. Please add to/comment on this list.
> Andrei

I assume we're mostly talking about spec stuff, not implementation stuff.  Nonetheless, to the extent that the GC API is considered part of the language spec, I think we need to fix that.

1.  My precise heap scanning patch has some ripple effects into the GC API and could affect what is done with the `new` operator. Therefore, we might not want to postpone this until after D2 is final.

2.  We should probably tighten up the spec to make sure that a moving, fully precise, etc. GC can be implemented at some point in the future without modifying the spec after D2 is declared gold.

Travis Boucher wrote:
> bearophile wrote:
>> Andrei Alexandrescu:
>>
>>> * Encode operators by compile-time strings. For example, instead of the plethora of opAdd, opMul, ..., we'd have this:
>>>
>>> T opBinary(string op)(T rhs) { ... }
>>>
>>> The string is "+", "*", etc.
>>
>> Can you show an example of defining an operator, like a minus, with that?
>>
> 
> T opBinary(string op)(T rhs) {
>     static if (op == "-") return data - rhs.data;
>     static if (op == "+") return data + rhs.data;
> 
>     // ... maybe this would work too ...
>     mixin("return data " ~ op ~ "rhs.data;");
> }
> 
> I love this syntax over the tons of different operation functions. Makes it so much nicer, especially when supporting a bunch of different paramater types (vectors are a good example of this).

Indeed, the advantage of this is that you can use string mixins to implement many operations at once, instead of laboriously defining many functions.


Andrei