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

Escape analysis is difficult when you don't have information about the functions you're passing the pointer to. For example:

void fun(int* p) {
    if (condition) gun(p);
}

Now the problem is that fun's escape-or-not behavior depends on flow (i.e. condition) and on gun's escaping behavior.

If we use @safe and @trusted to indicate unequivocally "no escape", then there is no analysis to be done - the hard part of the analysis has already been done manually by the user.

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

I agree.


Andrei

Andrei Alexandrescu wrote:
> The rewrite is done long after lexing, so no low-level problems there.

Oh, I thought it would let you introduce new operators. But it's only about the existing ones.

I find the idea to identify the operator using a string very sloppy and sillyl just like using string mixins for small delegates in std.algorithm etc.; but you'd probably say "it works and is useful" and "it's short" and "it solves the current problem", so... whatever.

On Wed, 18 Nov 2009 17:14:34 -0800, Andrei Alexandrescu wrote:

> Great, thanks.



"List looks very to the point"

Yeah no effort has been made to make it new comer friendly (not that there is a need too)

"and up to date."

Don has help out greatly for that.

grauzone wrote:
> Andrei Alexandrescu wrote:
>> The rewrite is done long after lexing, so no low-level problems there.
> 
> Oh, I thought it would let you introduce new operators. But it's only about the existing ones.
> 
> I find the idea to identify the operator using a string very sloppy and sillyl just like using string mixins for small delegates in std.algorithm etc.; but you'd probably say "it works and is useful" and "it's short" and "it solves the current problem", so... whatever.

We're trying to improve on the current situation, which forces the user to manually define a lot of small functions. If you have convincing reasons to argue that the current state of affairs is actually better, I'm all ears - both Walter and I could use less work, particularly if the outcome sucks (see e.g. T[new]). Also, if you have ideas on how things could be done in a way that you'd find not sloppy and not silly, that would be even better.


Andrei

Andrei Alexandrescu wrote:
> 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:

If that's such an issue, why don't you just change it and use a struct defined by the user? structs are natural name-value pairs that work at compile time, and they can always be returned from functions.

> 4. Allow private members inside a template using the eponymous trick:
> 
> template wyda(int x) {
>    private enum geeba = x / 2;
>    alias geeba wyda;
> }

Why is this important?

Apart from this...

Whatever happened to the concurrency stuff? Do you really want users to deal with the broken and incomplete implementation right now? What about the issues of constructing immutable data? (Eh, are we supposed to cast from mutable data, and hope everything goes right?) Right now, multithreaded programming in D2 is probably even more a pain than in C++.

Also, you should fix the auto-flattening of tuples before it's too late. I think everyone agrees that auto-flattening is a bad idea, and that tuples should be nestable. Flattening can be done manually with an unary operator.

(Introducing sane tuples (e.g. unify type and value tuples, sane and short syntax, and all that) can wait for later if it must. Introducing these can be downwards compatible, I hope.)

Andrei Alexandrescu wrote:
> grauzone wrote:
>> Andrei Alexandrescu wrote:
>>> The rewrite is done long after lexing, so no low-level problems there.
>>
>> Oh, I thought it would let you introduce new operators. But it's only about the existing ones.
>>
>> I find the idea to identify the operator using a string very sloppy and sillyl just like using string mixins for small delegates in std.algorithm etc.; but you'd probably say "it works and is useful" and "it's short" and "it solves the current problem", so... whatever.
> 
> We're trying to improve on the current situation, which forces the user to manually define a lot of small functions. If you have convincing reasons to argue that the current state of affairs is actually better, I'm all ears - both Walter and I could use less work, particularly if the outcome sucks (see e.g. T[new]). Also, if you have ideas on how things could be done in a way that you'd find not sloppy and not silly, that would be even better.

If I had a better proposal, I'd post it. I'm just saying that's it's a bad hack, that _although_ solves the problem, will have negative side effects for other reasons.

Does the current proposal make things simpler at all? All you're doing is to enable the programmer to "fix" the clumsy semantics by throwing lots of CTFE onto the problem. Why not generate the operator functions with CTFE in the first place...

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
> dsimcha wrote:
> > == 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?
> Escape analysis is difficult when you don't have information about the
> functions you're passing the pointer to. For example:
> void fun(int* p) {
>      if (condition) gun(p);
> }
> Now the problem is that fun's escape-or-not behavior depends on flow
> (i.e. condition) and on gun's escaping behavior.
> If we use @safe and @trusted to indicate unequivocally "no escape", then
> there is no analysis to be done - the hard part of the analysis has
> already been done manually by the user.

But then the @safe or @trusted function wouldn't be able to escape pointers to heap or static data segment memory either, if I understand this proposal correctly.

dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
>> dsimcha wrote:
>>> == 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?
>> Escape analysis is difficult when you don't have information about the
>> functions you're passing the pointer to. For example:
>> void fun(int* p) {
>>      if (condition) gun(p);
>> }
>> Now the problem is that fun's escape-or-not behavior depends on flow
>> (i.e. condition) and on gun's escaping behavior.
>> If we use @safe and @trusted to indicate unequivocally "no escape", then
>> there is no analysis to be done - the hard part of the analysis has
>> already been done manually by the user.
> 
> But then the @safe or @trusted function wouldn't be able to escape pointers to
> heap or static data segment memory either, if I understand this proposal correctly.
> 

Yah. The question is to what extent is that necessary.

Andrei

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
> dsimcha wrote:
> > == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
> >> dsimcha wrote:
> >>> == 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?
> >> Escape analysis is difficult when you don't have information about the
> >> functions you're passing the pointer to. For example:
> >> void fun(int* p) {
> >>      if (condition) gun(p);
> >> }
> >> Now the problem is that fun's escape-or-not behavior depends on flow
> >> (i.e. condition) and on gun's escaping behavior.
> >> If we use @safe and @trusted to indicate unequivocally "no escape", then
> >> there is no analysis to be done - the hard part of the analysis has
> >> already been done manually by the user.
> >
> > But then the @safe or @trusted function wouldn't be able to escape pointers to heap or static data segment memory either, if I understand this proposal
correctly.
> >
> Yah. The question is to what extent is that necessary. Andrei

Too kludgey for me.  I'd rather just see ref parameters get fixed and just don't allow taking the address of locals in @safe functions.  I'd say that, except in low-level systems programming that would probably not be @safe for other reasons anyhow, there would be very few good if any good reasons to take the address of a local if reference tuples just worked.

grauzone wrote:
> 
> If I had a better proposal, I'd post it. I'm just saying that's it's a bad hack, that _although_ solves the problem, will have negative side effects for other reasons.
> 
> Does the current proposal make things simpler at all? All you're doing is to enable the programmer to "fix" the clumsy semantics by throwing lots of CTFE onto the problem. Why not generate the operator functions with CTFE in the first place...

From my point of view (trying different ways of implementing something as simple as a vector), this makes things much simpler without sacrificing functionality.

Personally, I'd love to see an unknownMethod(string method)(...) thing implemented as well, but that might be asking for too much (and might sacrifice performance in some cases).