dsimcha wrote:
> == 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.

I think you can safely work on that asynchronously. TDPL won't include a "GC API Reference" - for that kind of stuff I think it's ok to refer to the online documentation.

Thanks for working on this!

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.

I thought the problem with this was that the lexer/parser would have to know about semantics, which is against the goals of the language. Would the operator actually be inside quotes?

Anyway, do we _really_ want to make it possible, that valid D code will look like ASCII art?

grauzone 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.
> 
> I thought the problem with this was that the lexer/parser would have to know about semantics, which is against the goals of the language. Would the operator actually be inside quotes?

It's simpler than that.

a + b

will be rewritten into

a.opBinary!("+")(b)

The rewrite is done long after lexing, so no low-level problems there.

> Anyway, do we _really_ want to make it possible, that valid D code will look like ASCII art?

We want to improve the state of the art. If the attempt risks to end up doing the opposite, I'm all ears.


Andrei

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.

Uniform function call syntax.

Kyle wrote:
> 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.
> 
> Uniform function call syntax.
> 

It's in the book. I'm adding this message as a reminder to add a test case. Thanks!

Andrei

Jesse Phillips wrote:
> 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.

Great, thanks. List looks very to the point and up to date.

Andrei

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.

Static function parameters

Kyle wrote:
> 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.
> 
> Static function parameters

Walter tried to implement them and ran into a number of odd semantic issues.

Andrei

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
> dsimcha wrote:
> > == 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.
> I think you can safely work on that asynchronously. TDPL won't include a
> "GC API Reference" - for that kind of stuff I think it's ok to refer to
> the online documentation.
> Thanks for working on this!
> Andrei

Can you clarify the higher level development model, then?

1.  Are we departing from the D1 model and allowing changes to Phobos after the language spec is declared final?  If so, can those changes be breaking, at least at the binary level?

2.  Are we punting on the GC API and allowing it to be implementation defined?  I thought this API was supposed to be stable and allow for swapping GC implementations at link time.  Then again, I think it's actually a bad idea to create such a stable API, since different GC implementations will require different configuration, meta-data, etc. and this is just a fact of life.  Most user code will not interact directly with the GC, but will use `new`, builtin arrays, etc.

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
> 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.

IMHO this is a terrible solution.  SafeD should not cause major ripple effects for pieces of code that don't want to use it.  I'm all for safe defaults even if they're less efficient or less flexible, but if D starts sacrificing performance or flexibility for safety **even when the programmer explicitly asks it not to**, then it will officially have become a bondage and discipline language.

Furthermore, as you point out, having the semantics of something vary in subtle ways between SafeD and unsafe D is probably a recipe for confusion.


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

This is a great idea if it can be implemented.  Isn't escape analysis a pretty hard thing to get right, though, especially when you might not have the source code to the function being called?

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

This should be done eventually regardless of what happens with taking addresses of locals, though I'm not sure it still makes the short list if we solve the addresses of locals thing some other way.