BUG: dict.lookupOrDefault<label> throws FATAL IO Error for E-notation number dict entry, but not for the same default value

Summary

Say the following functionObject exists with two optional entries which accept label types as input:

functions
{
    iAmFunctionObject
    {
        ...
        aSmallInteger       -1e9;
        aLargeInteger        1e9;
}

The label objects, i.e. aSmallInteger and aLargeInteger, are initialised in iAmFunctionObject's constructor via:

    iAmIntegerRange_
    (
        labelRange
        (
            dict.lookupOrDefault<label>("aSmallInteger", -1),
            dict.lookupOrDefault<label>("aLargeInteger", 1e9)
        )
    ),

• When these optional entries are not present under controlDict\functions\iAmFunctionObject: No FATAL IO ERROR occurs.
• When such an optional entry is present under controlDict\functions\iAmFunctionObject: The following is thrown:

--> FOAM FATAL IO ERROR: 
Wrong token type - expected label (int32), found on line 59: double 1000000000

Steps to reproduce

I can only provide a Minimal Working Example after the completion of the relevant functionObject, I am afraid.

What is NOT the bug?

The following does not throw an IO Error:

functions
{
    iAmFunctionObject
    {
        ...
        aSmallInteger       -1000000000;
        aLargeInteger        1000000000;
}

What is the expected correct behavior?

1. IMHO, this behaviour is inconsistent (yet might not be important as well) since one can input 1e9 as label when the object is default initialised; (that is dict.lookupOrDefault<label>("aLargeInteger", 1e9)), but not through a dictionary entry.
2. In addition, a user might expect for that any E-notation without a decimal point, e.g. 1e4 or -5e8, the type deduction will be label rather than scalar. However, it is also legitimate to throw such type deduction error for E-notations with decimal points, e.g. 1.0e4 or 1.3e4.

Environment information

OpenFOAM version : v1812

Operating system : openSUSE

Compiler : gcc