[PSR-12] Add space padding to both sides of a return declaration colon

[Alexander Makarov]

https://github.com/php-fig/fig-standards/pull/733

What it originally was is:

function doit(): boolean;

What's proposed is the following:

function doit() : boolean;

It's a single space after for many implementations so I don't think it's good to change it: http://www.typescriptlang.org/Handbook#interfaces

Thoughts?

[Woody Gilk]

I am not in favor, this seems unnecessary and doesn't make the code
easier to read.
--
Woody Gilk
http://about.me/shadowhand

> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/b62a4ac8-9733-422f-8246-c0850d2aac9b%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Matteo Beccati]

On 05/01/2016 12:03, Alexander Makarov wrote:
> What's proposed is the following:
>
> function doit() : boolean;
>
> It's a single space after for many implementations so I don't think it's
> good to change it: http://www.typescriptlang.org/Handbook#interfaces
>
> Thoughts?

Hmm, I don't like it, sorry.


Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

[Larry Garfield]

On 1/5/16 8:56 AM, Matteo Beccati wrote:
> On 05/01/2016 12:03, Alexander Makarov wrote:
>> What's proposed is the following:
>>
>> function doit() : boolean;
>>
>> It's a single space after for many implementations so I don't think it's
>> good to change it: http://www.typescriptlang.org/Handbook#interfaces
>>
>> Thoughts?
> Hmm, I don't like it, sorry.
>
>
> Cheers

Woody and Matteo: Have you a reasoned argument more robust than "I don't
like it"? The argument for the switch is based on consistency with the
rest of the document, as demonstrated previously. "I don't wanna" is
not a particularly compelling counter-argument. :-)

--
--Larry Garfield

[Woody Gilk]

Larry,

It would help if you linked to the previous discussion instead of
saying "as discussed on the list".

If you are asking for a change, you need to provide a reasonable
argument as to why. It seems you've already done so, but in a very
hand-wavy fashion, rather than properly citing your source.

Regards,

--
Woody Gilk
http://about.me/shadowhand

> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig/568BDB1C.6000604%40garfieldtech.com.

[Alexander Makarov]

Another argument is that in natural languages ":" is used without a space before it and with a space after it.

[Jeremy Lindblom]

Hack/HHVM docs show examples with no space before: https://docs.hhvm.com/hack/types/type-system

Are there any other programming languages that have return types defined in a similar manner that we could review?

--
Jeremy Lindblom (@jeremeamia)
Software/Platform Engineer at Engrade (part of McGraw-Hill Education)

Co-founder of the Pacific Northwest PHP Conference (@PNWPHP)

Co-author of the AWS SDK for PHP (@awsforphp)

PHP-FIG Representative for the Guzzle project

Looking for a senior-level software engineering position doing PHP? I have some available with McGraw-Hill Education in Seattle and Los Angeles (Santa Monica or Irvine). Contact me for me more information.

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/fc5e1c18-f703-4835-b5aa-d99e03ab2a04%40googlegroups.com.

[Larry Garfield]

Go has post-fix return types, but no syntax marker:

func (varname Type) retType {

}

Or if doing multiple returns:

func (varname Type) (retType1, retType2) {

}

https://github.com/golang/go/wiki/CodeReviewComments

Rust's coding style guide is [FIXME]:

https://aturon.github.io/style/README.html

However, the example code puts spaces on either side of the syntax marker:

// Function that returns a boolean value
fn is_divisible_by(lhs: u32, rhs: u32) -> bool {
// Corner case, early return
if rhs == 0 {
return false;
}

// This is an expression, the `return` keyword is not necessary here
lhs % rhs == 0
}

http://rustbyexample.com/fn.html

If I'm reading it correctly, Scala uses a colon with no preceding space:

http://www.scala-lang.org/old/node/223.html

(Disclaimer: I've never actually written in Rust or Scala.)

Those are the other postfix-return-type languages I know of off hand.
So that's one for double-padding, one for single-padding, and one N/A. :-)

On 1/5/16 1:47 PM, Jeremy Lindblom wrote:
> Hack/HHVM docs show examples with no space before:
> https://docs.hhvm.com/hack/types/type-system
>
> Are there any other programming languages that have return types
> defined in a similar manner that we could review?
>
> --

> *Jeremy Lindblom (@jeremeamia <https://twitter.com/jeremeamia>)*
> Software/Platform Engineer at Engrade <https://engrade.com/> (part of
> McGraw-Hill Education <http://www.mheducation.com/>)

> Co-founder of the Pacific Northwest PHP Conference

> <http://pnwphp.com/> (@PNWPHP <https://twitter.com/pnwphp>)

> Co-author of the AWS SDK for PHP

> <http://aws.amazon.com/sdkforphp/> (@awsforphp
> <https://twitter.com/awsforphp>)
> PHP-FIG <http://www.php-fig.org/> Representative for the Guzzle
> <http://guzzlephp.org/> project

>
> Looking for a senior-level software engineering position doing PHP? I
> have some available with McGraw-Hill Education in Seattle and Los
> Angeles (Santa Monica or Irvine). Contact me for me more information.
>
>
> On Tue, Jan 5, 2016 at 10:49 AM, Alexander Makarov
> <alexande...@googlemail.com

> <mailto:alexande...@googlemail.com>> wrote:
>
> Another argument is that in natural languages ":" is used without
> a space before it and with a space after it.
>
> On Tuesday, January 5, 2016 at 2:03:42 PM UTC+3, Alexander Makarov
> wrote:
>
> https://github.com/php-fig/fig-standards/pull/733
>
> What it originally was is:
>
> function doit(): boolean;
>
> What's proposed is the following:
>
> function doit() : boolean;
>
> It's a single space after for many implementations so I don't
> think it's good to change it:
> http://www.typescriptlang.org/Handbook#interfaces
>
> Thoughts?
>

--

--Larry Garfield

[Richard Fussenegger]

Thanks Alexander for opening this thread. I was startled too by the bold merge request from Larry without any consens in the thread. From the other thread:

On Monday, January 4, 2016 at 11:53:36 PM UTC+1, Larry Garfield wrote:

On 1/4/16 2:03 PM, Richard Fussenegger wrote: 
> The target in programming is always to match natural language as close 
> as possible, 

This statement is untrue.  There are language in which mapping to a 
human language (generally English) is a design goal, but that is not 
even remotely universal.  I don't recall it being an explicit design 
goal of PHP either. 

-- 
--Larry Garfield 

You are absolutely right Larry, the statement of mine was way to broad. However, it is advocated to do so in an OO context by many domain experts and I like that approach. I do not know what the design goals of PHP were or currently are in this regard. That being said, let us approach the problem in a more scientific way by listing the arguments for and against the current two options. (Note: you can copy paste the examples to your console and execute them with PHP 7; just to have some real world examples here.)

#1 No Space After Closing Bracket

$ php -r '$x = "42\n"; echo (function () use ($x): string { return $x; })();'
$ php -r 'function fn(string $x): string { return"42\n"; } echo fn();'

+ Consistent with the missing space between function/method name and opening bracket.

+ Consistent with PHP manual (RFC and Hack manual).

+ Matches natural English language writing behavior.*

+ Used by the majority of existing PHP 7 code bases.**

+ Used by Scala.

+/− Consistent with other colon placements in PHP (case and goto).

− Inconsistent with the space after the function/method and use keyword.

+ Creates a unique and unified visual entity (started by the name plus bracket and terminated by bracket plus colon):*** function name($p1, $pn) use ($a1, $an): ReturnType

#2 Space After Closing Bracket

$ php -r '$x = "foo"; echo (function () use ($x) : string { return $x; })();'

$ php -r 'function fn() : string { return"42\n"; } echo fn();'

+ Consistent with the space after the function/method and use keyword.
+/− Used by Rust?

+/− Inconsistent with other colon placements in PHP (case and goto).

− Not used by the majority of existing PHP 7 code bases.**

− Inconsistent with the missing space between name and opening bracket.

− Inconsistent with PHP manual (RFC and Hack manual).

− Mismatches natural English language writing behavior.*

− Destroys the unique and unified visual entity (started by name plus bracket and terminated by bracket [plus space] plus colon):*** function name($p1, $pn) use ($a1, $an) : ReturnType

* Note: The fact that there is no space between the name and the opening bracket would be an argument against this argument, however, the omission of that space is justified through the unified visual entity argument. I also think that there is no discussion required in regards to placing a space between name and opening bracket. (Otherwise I will raise the question about spaces within all kinds of brackets and in front of every symbol, including our terminator friend the semicolon.)

** As surveyed by the PSR-12 editor/working group, as stated by Michael Cullum in the origin thread, and I believe them because I've never seen it otherwise as of yet.

*** I placed the unique and unified visual entity rule on an extra line because it is not a very strong point and some might disagree.

I truly hope that this helps to make the factual situation more clear. I think it is obvious which option I prefer (#1 just to be clear).

[Alexander Makarov]

Richard, that was me who asked Larry to open these pull requests because I'm often lost in mailing list threads. Especially after new year celebration. These are just easier to review and discuss.

btw., another thing in favor of no space before ":" is PHP guide: https://secure.php.net/manual/en/functions.returning-values.php#functions.returning-values.type-declaration

[Korvin Szanto]

I think that it's pretty clear from examples here that people tend toward no preceding space, however I still agree with Larry's original argument that to be consistent we must have the space on either side. That said, I personally have done both in my own code and really notice no difference in readability / ease of writing so I'm happy with either recommendation as long as we choose one way or the other.

This question will be part of the poll, lets hold off on making a real decision on this until we see the results of that.

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/07f5f309-5682-4b67-8b7f-9fc763710aa4%40googlegroups.com.

[Richard Fussenegger]

On Tuesday, January 5, 2016 at 10:41:35 PM UTC+1, Alexander Makarov wrote:

Richard, that was me who asked Larry to open these pull requests because I'm often lost in mailing list threads. Especially after new year celebration. These are just easier to review and discuss.

My bad, sorry Larry.

On Tuesday, January 5, 2016 at 10:41:35 PM UTC+1, Alexander Makarov wrote: 

btw., another thing in favor of no space before ":" is PHP guide: https://secure.php.net/manual/en/functions.returning-values.php#functions.returning-values.type-declaration

+1

On Tuesday, January 5, 2016 at 4:03:05 PM UTC+1, Larry Garfield wrote:

"I don't wanna" is not a particularly compelling counter-argument. :-)

On Tuesday, January 5, 2016 at 11:13:01 PM UTC+1, Korvin Szanto wrote:

This question will be part of the poll, lets hold off on making a real decision on this until we see the results of that.

It is back to opinions then. I truly hope that that poll is not going to be the only source and requires a true majority (at least 80%) for one approach to actually affect the outcome of this discussion. 

[Korvin Szanto]

The poll won't be the only thing considered but I imagine that we will look to the results for tie breakers when we can't come to an objective conclusion.

Another example I noticed today: If you hold command and hover over a function call in PHPStorm, it shows the signature with the leading space.

[Richard Fussenegger]

On Wednesday, January 6, 2016 at 10:26:23 PM UTC+1, Korvin Szanto wrote:

The poll won't be the only thing considered but I imagine that we will look to the results for tie breakers when we can't come to an objective conclusion.

Good. 

 

On Wednesday, January 6, 2016 at 10:26:23 PM UTC+1, Korvin Szanto wrote: 

Another example I noticed today: If you hold command and hover over a function call in PHPStorm, it shows the signature with the leading space.

… and without leading space in the Quick Info panel (Ctrl + Q on Linux and Windows). So I guess PhpStorm is a bad and inconsistent example here.