Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111376
To: internals@lists.php.net
References: <DM6PR07MB6618330329EA36D0FEC1EFBEF9460@DM6PR07MB6618.namprd07.prod.outlook.com>
 <5f2e9e38.1c69fb81.a2272.df96SMTPIN_ADDED_MISSING@mx.google.com>
Message-ID: <639cc522-998c-5886-8ed7-39086c91b0dd@gmail.com>
Date: Sat, 8 Aug 2020 15:59:31 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <5f2e9e38.1c69fb81.a2272.df96SMTPIN_ADDED_MISSING@mx.google.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Re: Proposal: shorthand syntax for initializing
 arbitrary-precision("bigint") numbers?
From: rowan.collins@gmail.com (Rowan Tommins)

On 08/08/2020 13:44, Andrea Faulds wrote:
> 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


That reminds me more of C++'s "user-defined literals"; 
https://docs.microsoft.com/en-us/cpp/cpp/user-defined-literals-cpp?view=vs-2019 
has a decent introduction, and https://stackoverflow.com/q/237804/157957 
some discussion of their advantages. As you say, they are basically 
sugar around a function call (implemented in C++ as an operator 
overload, because that's a hammer they had available).

An interesting advantage in PHP would come if we could limit literals to 
be computable at compile-time:

* They could be pre-computed and cached on compilation, saving a 
function call.
* They could be used in restricted contexts such as constant definitions 
and parameter defaults.

Initially, this would probably mean restricting them to built-in types, 
but could potentially be opened up to userland later once some other 
pieces were in place (structs feel closely related).


Regardless of the syntax, having a BigNum type constructible at 
compile-time would be a big advantage over GMP, especially if it could 
be generalised to expressions of multiple BigNums:

const GOOGOL = 10_bignum ** 100; // type of result inferred from one 
operand, in the same way that 10*2 !== 10.0*2
const GOOGOLPLEX = 10 ** GOOGOL; // type of result inferred from 
existing constant

function waste_time(BigNum $iterations = GOOGOLPLEX) { ... }


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]