On Monday, 11 July 2016 at 16:27:38 UTC, Andrew Godfrey wrote:
> [...]
>
> * It must not be ignorable by the compiler.
>
> * It must generate an error if that compiler would be unable to do the TCO. Otherwise, the compiler *may* (not "must") apply the TCO, unless compiled under (some optimization level, please specify), in which case it *must* apply TCO.
>
> One difficulty with this is the words "that compiler". I.e. other compilers are free to be unable to make the TCO. This means that by using this feature, you have made your code non-portable.

I think that noticing problems while porting it it's better than having it crash unexpectedly as it would currently happen.


> P.S. You have proposed annotating the function with @tco - it seems more like it's the call site that needs to be annotated.

I'm not sure about how to do annotations on the call site. Would a new keyword be required?

On Monday, 11 July 2016 at 17:31:23 UTC, Dietrich Daroch wrote:
> On Monday, 11 July 2016 at 16:27:38 UTC, Andrew Godfrey wrote:
>> [...]
>>
>> * It must not be ignorable by the compiler.
>>
>> * It must generate an error if that compiler would be unable to do the TCO. Otherwise, the compiler *may* (not "must") apply the TCO, unless compiled under (some optimization level, please specify), in which case it *must* apply TCO.
>>
>> One difficulty with this is the words "that compiler". I.e. other compilers are free to be unable to make the TCO. This means that by using this feature, you have made your code non-portable.
>
> I think that noticing problems while porting it it's better than having it crash unexpectedly as it would currently happen.

Sure, non-portability that causes a guaranteed compiler error, is better than other kinds of non-portability. But it's still non-portable. That is distasteful enough that you probably need to make a more compelling case; factorial is a "toy" function that's not enough - on its own - to justify adding a feature.

I personally feel like it is a neat idea, and it may enable some programming styles that I'm not familiar with so I can't say they definitively they have no value. The reason I'm not familiar with them could be that I've never had this feature in a language I've used a lot. So there could be something here, BUT I also think it would need to be a portable feature, which implies much more rigorous rules that all compilers would have to follow. (They could still do TCO for more complicated situations, but those wouldn't interact with this feature; to make use of this feature you'd have to conform to the more rigorous rules).


>> P.S. You have proposed annotating the function with @tco - it seems more like it's the call site that needs to be annotated.
>
> I'm not sure about how to do annotations on the call site. Would a new keyword be required?

I don't know this. (E.g. Are attributes allowed at the beginning of a statement?)

On Tuesday, 12 July 2016 at 01:42:13 UTC, Andrew Godfrey wrote:
> On Monday, 11 July 2016 at 17:31:23 UTC, Dietrich Daroch wrote:
>> On Monday, 11 July 2016 at 16:27:38 UTC, Andrew Godfrey wrote:
>>> [...]
>>>
>>> * It must not be ignorable by the compiler.
>>>
>>> * It must generate an error if that compiler would be unable to do the TCO. Otherwise, the compiler *may* (not "must") apply the TCO, unless compiled under (some optimization level, please specify), in which case it *must* apply TCO.
>>>
>>> One difficulty with this is the words "that compiler". I.e. other compilers are free to be unable to make the TCO. This means that by using this feature, you have made your code non-portable.
>>
>> I think that noticing problems while porting it it's better than having it crash unexpectedly as it would currently happen.
>
> Sure, non-portability that causes a guaranteed compiler error, is better than other kinds of non-portability. But it's still non-portable. That is distasteful enough that you probably need to make a more compelling case; factorial is a "toy" function that's not enough - on its own - to justify adding a feature.
>
> I personally feel like it is a neat idea, and it may enable some programming styles that I'm not familiar with so I can't say they definitively they have no value. The reason I'm not familiar with them could be that I've never had this feature in a language I've used a lot. So there could be something here, BUT I also think it would need to be a portable feature, which implies much more rigorous rules that all compilers would have to follow. (They could still do TCO for more complicated situations, but those wouldn't interact with this feature; to make use of this feature you'd have to conform to the more rigorous rules).

I've thought about using pragmas and they would allow for an easier implementation if ignored pragmas raise warnings (and errors with strict flags) when a pragma was ignored.

Under that setup, people who need the errors can enable the flags, while people who doesn't care about this can just ignore/disable the warnings and keep their programs without need for rewrite.

Also, using pragmas requires no change on the grammar, nor adding new attributes that most people really dislike (I still don't get why, probably the text editors should take care to make them less distracting or even hiding them).

On Monday, 11 July 2016 at 11:19:59 UTC, Dicebot wrote:
> D language authors don't want to enforce any code of conduct or moderation in the newsgroup which means certain personas have to be simply ignored.

This is not a policy that will scale well. Ketmar's behaviour was badly out of line. People need to save the scathing pseudo-Linus stuff for the inner-circle rather than new comers.

On Sunday, 10 July 2016 at 05:03:46 UTC, Dietrich Daroch wrote:
> Hi everyone (=
>
> I've just added a new proposal to add a new attribute to ensure TCO is applied.
>
> The proposal is really simple, but I'm clueless on how to implement it and also interested on getting feedback on it.
>

In contrast to what many folks expect, TCO is affecting program semantics in a way that changes stack overflow to normal execution.

Therefore it's not an optimization but part of semantics, and there should be a way to mark a call as a tail-call in any optimization level.

It was a big road block for me when I tried to implement threaded-code interpreter, because it will stack overflow in debug mode.

>
> The proposal it's ready for merge on the new [DIPs repo](https://github.com/dlang/DIPs/pull/6)
>
> --
> Dietrich

On Tuesday, 12 July 2016 at 10:46:01 UTC, Dmitry Olshansky wrote:
> On Sunday, 10 July 2016 at 05:03:46 UTC, Dietrich Daroch wrote:
>> Hi everyone (=
>>
>> I've just added a new proposal to add a new attribute to ensure TCO is applied.
>> [...]
>
> In contrast to what many folks expect, TCO is affecting program semantics in a way that changes stack overflow to normal execution.
>
> Therefore it's not an optimization but part of semantics, and there should be a way to mark a call as a tail-call in any optimization level.


Yes, it's not a tiny detail that improves performance a bit, but it decides wheter the built binary works or not.


Also, some people are against breakage, but having a correctly built binary that may surprise you with a stack overflow when ported is not something I would call real portability.