Sometimes we use “returns”, other times we use “-->” to indicate return type

[AlexDaniel]

I think we can be a bit more consistent. Perhaps “returns” is better because it is more readable, but I don't mind as long as it is consistent.

[tbrowder]

I vote for "returns.". To me it looks cleaner, and I suspect it's more self-explanatory and less confusing for inexperienced Perl Sixers.

[Altai-man]

Judging by

> grep -I -r ' \-\-> ' doc/Type/* | wc -l
53
> grep -I -r ') returns ' doc/Type/* | wc -l
609

(my branch is pretty old, but I don't think there will be much difference with up-to-date) the second way is much more used, so it will be easier to shift to this one.

Seems like a quite easy grep-emacs-macro-job(and there are not so many lines to review, only about 50+), so I can do it tomorrow or the day after tomorrow if nobody is against.

[coke]

If we're going to enforce this style, we'll need a test for it. Otherwise it'll creep back in later.

[Altai-man]

If the test can be simple, something like https://github.com/perl6/doc/blob/master/t/tabs.t, then it is not so hard to actually write one, just check for --> absence under Type/* directories.

[Altai-man]

Accordingly to https://irclog.perlgeek.de/perl6/2016-12-03#i_13673364 the current state of the issue is:
1)--> and returns(and all other ways to declare return type) have a difference: --> can be used with pure value, while others don't. We do have signatures with pure values, so the single style is a bad option(in my opinion).

With this in mind, I'm not sure we need some radical changes in this area, to be honest.

Of course, we can change all signatures to -->, but they are not in majority currently. On the other hand, we can use some distinction like:
1)Use returns if method doesn't return value.
2)Use --> otherwise.
It will be consistent and can be checked by our mechanism of running examples. What do you think about such way of "consistency", @AlexDaniel?

And I don't think it is a big problem, since https://docs.perl6.org/type/Signature#Constraining_Return_Types has a quite proper explanation of all ways to express return type. However, it will be great to expand this section with a notice about the difference between styles above.

[AlexDaniel]

@Altai-man that's a good idea I think.

[AlexDaniel]

It will make it harder to write a test for it though :)

[Altai-man]

The situation with a test is:

• Using our extract-examples we can check that all signatures can be compiled, so it doesn't need something new in this case.
• However, we don't spot cases when someone will write --> Int, when it "should" be returns Int and it will be valid for the compiler. No, we still can check all the types by hands with "check --> Int, check --> Range, etc-etc", but I'm not sure about performance of such solution.
• On the other hand, I really don't think there will be some very-very big changes in our method/routine scope. It's not the reason to not write tests, though.

With all that in mind, our current plan can be like this:

• Change --> to returns where it can be compiled without -->.
• Document the difference between styles(much more important, since it is confusing) - likely to be fixed with the new issue referenced below).
• Write a proper test!
• Close this issue!

[AlexDaniel]

@Altai-man what about the rest? I think the stuff in doc/Language/setbagmix wants to be changed too?

[AlexDaniel]

See this for discussion: https://irclog.perlgeek.de/perl6/2016-12-03#i_13674580

The pull request for converting --> to returns was first merged and then reverted. The reason for this is that it seems like we did a mistake by choosing returns as the preferred option. Please discuss!

Basically, the only reason to choose returns is because arguably it is more readable. But if it will be gone in v6.d, I guess there is no good justification for flogging the dead horse.

[Altai-man]

The reverse PR is on its way...

[Altai-man]

Closed with #1035 merge.

[Altai-man]

Language/ now is tested and pass tests(AFAIK) too, see 4d74a9b. Just to keep track of things.