Hi Andrea,

> > What are your thoughts on making `123_456_000_000_000_000_000_000n` a 
> > shorthand for `gmp_init('123456000000000000000000')` (or a call with 
> > equivalent results)
> > (similar to existing backtick string syntax is a shorthand for 
> > `shell_exec()`)
> 
> We could do that, but maybe this is a good opportunity to do something 
> with a wider benefit than GMP by having a generalised solution? GMP is 
> already special in some ways and it would be a shame to have even more 
> functionality that privileges it.
> 
> For example, what if we allowed string prefixes to have special 
> user-defined meanings, like:
>
>   n"123_456" // expands to: gmp_init('123_456')
>   u"foo bar" // expands to: new UnicodeString("foo bar") (some class I 
made up)
>   d"123.456" // expands to: new Decimal("123.456") (also an imaginary 
class)
> 
> This would be a similar idea to JavaScript's template string tags: 
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals
> 
> How you'd define the mappings from prefixes to executed code, I'm not 
> sure, but we could just make it call a function by that name in the 
> current namespace… though that would prompt the question “why not just 
> write `d("123.456")`, which is already possible?” and I don't have a 
> good answer to that :)

I'd feel like the former syntax would be more readable/familiar.

https://en.cppreference.com/w/cpp/language/user_literal also exists. It 
supports literals like `2.0_km` or `"one"_w.
`void operator "" _km(long double); // OK, will be called for 1.0_km`
A brand new type of operator function separate from global functions (possibly 
with autoloading) would be one possible way to execute that.

That being said, I don't know extending that syntax to user-defined functions 
would pass as an RFC, and I don't personally interest in adding it.

- In C++, you'd know if there was a bug at compile time.
  The C++ compiler would tell you that the program could not contain `1.0_km + 
1.0_Litres` or `1.0_km + 2` before the program could run.
- Maybe this could be initially limited to C extensions (PECLs) during 
initialization?
  The ability to perform operations on user-defined classes is limited because 
https://wiki.php.net/rfc/userspace_operator_overloading didn't pass. 
- User-defined operators would also enable code like `$x = 
download_url"https://....";`, which may cause confusion reviewing code but 
should hopefully be rare in practice.
- If somebody ended up adding user-defined literal syntaxes, I'd really hope 
that those would be separate from global function symbols and unambiguously 
resolved (e.g. by not having namespaces, or by requiring that the operator be 
explicitly imported to be used)
- Different frameworks may end up with conflicting definitions of the same 
operator for short operators.
- Also, there'd be no indication if there were typos such as `$a = yeeld"END";` 
and I'm not sure how lexing would work with prefixes. Suffixes may work, I'm 
not sure.

Thanks,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to