Re: Object Type Casting Reloaded

> On 23 Apr 2019, at 16:03, Benjamin Morel <benjamin.morel@gmail.com> wrote: > > > I like the idea but I find the syntax (both suggestions) less than great, given that > > there’s already “ensure a type” syntax, and both suggestions are already used for other things > > (casting and foreach) > > Note that we already use as in other contexts than foreach: in > imports (use Foo as Bar) and in traits (use > SomeTrait { foo as bar; }) , so I think that reusing the keyword for yet another use > case is OK, as long as it does not conflict. > > > Is there some reason (eg ambiguities) a type can’t just be placed before a variable to > > ensure a type, similar to a function parameter or typed property? > > string $foo = 'bar'; > > ... > > I’m talking about exactly the same functionality that exists with method parameters - > > constraining the type it must conform to when it is declared. Nothing more nothing less. > > I would personnally read this as "this variable is now strongly typed, INCLUDING later > assignments" (which would belong to another feature / discussion), but as you have later > clarified that this is not what you had in mind, I think that this syntax is then even more > confusing than the other proposals: > > Foo $foo = new Foo(); > $foo = 123; // this would work? > > > Using as means trying to add type constraints to an > > iterable in the foreach would be ridiculously confusing: > > foreach ( $foo as $K as int => $v as string) {...} > > Please note that my proposal is specific to class/interface names, not other types for now (I > could consider broadening it if people are interested in the suggested "as" syntax from > Hack). > Anyway with the two syntaxes suggested so far, you would not inline it in the foreach, but > explicitly write: > > foreach ($foos as $foo) { > $foo = (Foo) $foo; > // or > $foo = $foo as Foo; > } > > Hi Ben, My objection to as is that it specifically prevents (or makes very confusing) the foreach use I mentioned. There’s no variables involved in imports/traits, and neither of those relates to foreach. As for the string $foo = $bar->getFoo(); ‘looking strongly typed’ and wondering if it will allow re-declaration - do you think the same when you see function (string $foo) { $foo = explode(‘ ‘, $foo); } ? Functions have allowed type hints since 5.0 - nearly 15 years ago, and nobody seems to be confused if those variables can be redeclared. Whether you *should* redeclare them to a different value is something you need to decide for yourself. As for limiting this to class/interface names - why would you do that? It took YEARS to get scalar type hints for function parameters, why would you not include them from the start on anything new that pertains to essentially the same functionality? I can’t even begin to comprehend how re-assigning a variable to itself (even if it is a no-op internally, it *appears* to re-assign) to do a type check seems like a good option. Cheers Stephen