On Sunday, 10 July 2016 at 06:18:41 UTC, Jack Stouffer wrote:
> On Sunday, 10 July 2016 at 05:55:50 UTC, Dietrich Daroch wrote:
>> Yes, it probably does TCO. The problem is what if you think it does and it cannot do it because of a misunderstanding on when it can be applied or a bug?
>
> Then file a bug report?


Not a bug on the compiler, but on the function you expect to be tail recursive.

On Sunday, 10 July 2016 at 06:17:08 UTC, ketmar wrote:
> On Sunday, 10 July 2016 at 05:55:50 UTC, Dietrich Daroch wrote:
>> Yes, it probably does TCO. The problem is what if you think it does and it cannot do it because of a misunderstanding on when it can be applied or a bug?
>
> there can't be any "misunderstanding" from compiler side. either it is a leaf return, or not -- it is as easy as that. what your DIP is aimed for is brain-damaged coders who are not able to understand how programs work (and why "scope(exit)" may prevent TCO). it won't help anyone. sorry.

Yes, there is no cure for poor skills, but the point is to prevent the need to avoid recursion to ensure there are no stack overflows. It seems reasonable considering D targets systems programming.

On Sunday, 10 July 2016 at 06:29:43 UTC, A.B wrote:
> Get fucked by yourself asshole ! Your penance is that you'll have to review all the crappy DIPs that will come on GH until your death, now that anyone can post his fantastic idea easily.
>
> Hahahahaha.

Go back to >>>/g/

On Sunday, 10 July 2016 at 06:44:22 UTC, Dietrich Daroch wrote:
> Yes, there is no cure for poor skills, but the point is to prevent the need to avoid recursion to ensure there are no stack overflows. It seems reasonable considering D targets systems programming.

i see "system programmer" as someone who is able to understand when TCO is in effect without additional attribute noise. and for others it just doesn't matter -- as they probably is using a library written by "system programmer" anyway, and won't dive into code. ;-)

sorry, it is really just a noise, like "@nogc". compiler does a fairly good work on TCO already, and adding another attribute will just make code messier. it is already @too @many @attributes @in @D.

On Sunday, 10 July 2016 at 06:47:47 UTC, Jack Stouffer wrote:
> On Sunday, 10 July 2016 at 06:29:43 UTC, A.B wrote:
>> Get fucked by yourself asshole ! Your penance is that you'll have to review all the crappy DIPs that will come on GH until your death, now that anyone can post his fantastic idea easily.
>>
>> Hahahahaha.
>
> Go back to >>>/g/

what does that (>>>/g/) mean ?

On Sunday, 10 July 2016 at 06:59:21 UTC, ketmar wrote:
> On Sunday, 10 July 2016 at 06:44:22 UTC, Dietrich Daroch wrote:
>> Yes, there is no cure for poor skills, but the point is to prevent the need to avoid recursion to ensure there are no stack overflows. It seems reasonable considering D targets systems programming.
>
> i see "system programmer" as someone who is able to understand when TCO is in effect without additional attribute noise. and for others it just doesn't matter -- as they probably is using a library written by "system programmer" anyway, and won't dive into code. ;-)
>
> sorry, it is really just a noise, like "@nogc". compiler does a fairly good work on TCO already, and adding another attribute will just make code messier. it is already @too @many @attributes @in @D.


If attributes look messy, pragma can be used.

It may look as an addition with little gain, but one of the reasons of compiling is to prevent runtime errors as early as possible and this seeks exactly that.

On Sunday, 10 July 2016 at 07:30:32 UTC, Dietrich Daroch wrote:
> If attributes look messy, pragma can be used.
>
> It may look as an addition with little gain, but one of the reasons of compiling is to prevent runtime errors as early as possible and this seeks exactly that.

then TCO should be added to language spec too. for now, compiler is not obliged to implement it. also, many implementations only implement TCO for functions with exactly same args -- is this something that should be speced, or not?

we already has one optimization case speced -- NRVO. and it is BAD. adding another implementation detail to the spec will only worsen the situation, i believe.

On Sunday, 10 July 2016 at 07:43:14 UTC, ketmar wrote:
>
> we already has one optimization case speced -- NRVO. and it is BAD. adding another implementation detail to the spec will only worsen the situation, i believe.

We have other cases cases where optimization is expected but it is poorly speced.
However I like the fact that the spec does demand some optimizations because it ensures the quality of a conforming implementation.

Yet, TCO in particular it not applicable directly in many cases, and usually needs many transformations before it can be applied.

There nothing wrong with guaranteeing that it will be applied in trivial cases.
(This should be done by adding a sentence to the spec, not by adding a pargma)
However for more complex cases it heavily depends on the optimizer and on the backend!

In general you don't want to relay in such optimizations.
When in doubt avoid recursion.

On Sunday, 10 July 2016 at 06:39:06 UTC, ketmar wrote:
> On Sunday, 10 July 2016 at 06:37:18 UTC, ketmar wrote:
>> On Sunday, 10 July 2016 at 06:20:59 UTC, Seb wrote:
>>> ... guys, please stay friendly, constructive and polite! I thought we are all grown-ups here!
>>
>> i do. someone who is not able to understand when and how TCO works is clearly brain-damaged. if he isn't, why did he become programmer in the first place? it is clear that he is not able to program.
>
> note that i didn't said this about OP, in no way. so no personal attacks here.

Your joking right? No personal attacks?

On Sunday, 10 July 2016 at 09:05:46 UTC, Tofu Ninja wrote:
> Your joking right? No personal attacks?

where do you see personal attack in my words? i'm not saying that OP is dumb, and i'm not saying that his proposal is dumb. but it is *aimed* to dumb people (which doesn't automatically makes it dumb, you know). and i got tired of being "polite", from now on when i'll see dumb people, i'll say that i see dumb people, not "different" or "mentally impaired".

as for the topic, i *tried* to explain why i see no value in the proposal. and part of the explanation included referring to "brain-damaged coders".

but yeah, this (again) reminded me why i once resigned from NG. i'd probably should do it again, IRC is enough.