> > I also like Levi's proposal but for the use cases which lead me to the > idea for this proposal where I explicitly want to cast values and don't > check their current types it's difficult to use. I think it serves > different use cases. >
My personal pov is that the use case you describe is not sound enough to require a new syntax; this is still fine and explicit (borrowing from one of your examples), especially considering the weak points noted by Rowan: $now = (int) $a[0]; $future = (int) $a[1]; The huge benefit of Levi's proposal is that it works with any types, not just the castable ones: any class/interface would fit there. This means this new syntax would provide another "type barrier" that could help the engine or any type analyzer get a better understanding of the variables at hand. > You mention the syntax looks weird to you. How would you design the > syntax if you want to cast the values instead of type checking them? > I would abstain from trying to answer then. I now understand you had this different use case in mind, so I would totally understand that in turn, you'd be not interested in working towards Levi's proposal. On the other hand, I would so much like you'd be :) Cheers, Nicolas
