From @cpansprout

This is fine​:

$ perl -e '$VERSION=10e40; VERSION main 1'

This is not​:

$ perl5.15.9 -e '$VERSION="".10e40; VERSION main 1'
Invalid version format (non-numeric data) at -e line 1.

Those should both be treated the same way, as $VERSION stringifies and nummifies the same way in both cases.

Flags​:
  category=core
  severity=low

Site configuration information for perl 5.16.0​:

Configured by sprout at Thu May 10 22​:07​:00 PDT 2012.

Summary of my perl5 (revision 5 version 16 subversion 0) configuration​:
 
  Platform​:
  osname=darwin, osvers=10.5.0, archname=darwin-thread-multi-2level
  uname='darwin pint.local 10.5.0 darwin kernel version 10.5.0​: fri nov 5 23​:20​:39 pdt 2010; root​:xnu-1504.9.17~1release_i386 i386 '
  config_args='-de -Duseithreads -Dmad -Dusedevel'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=undef, use64bitall=undef, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include',
  optimize='-O3',
  cppflags='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.2.1 (Apple Inc. build 5664)', gccosandvers=''
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /usr/lib
  libs=-ldbm -ldl -lm -lutil -lc
  perllibs=-ldl -lm -lutil -lc
  libc=, so=dylib, useshrplib=false, libperl=libperl.a
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
  cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector'

Locally applied patches​:
  RC0

@​INC for perl 5.16.0​:
  /usr/local/lib/perl5/site_perl/5.16.0/darwin-thread-multi-2level
  /usr/local/lib/perl5/site_perl/5.16.0
  /usr/local/lib/perl5/5.16.0/darwin-thread-multi-2level
  /usr/local/lib/perl5/5.16.0
  /usr/local/lib/perl5/site_perl
  .

Environment for perl 5.16.0​:
  DYLD_LIBRARY_PATH (unset)
  HOME=/Users/sprout
  LANG=en_US.UTF-8
  LANGUAGE (unset)
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/usr/bin​:/bin​:/usr/sbin​:/sbin​:/usr/local/bin​:/usr/X11/bin​:/usr/local/bin
  PERL_BADLANG (unset)
  SHELL=/bin/bash

From @JohnPeacock

On Sun May 20 13​:25​:16 2012, sprout wrote​:

This is fine​:

$ perl -e '$VERSION=10e40; VERSION main 1'

This is not​:

$ perl5.15.9 -e '$VERSION="".10e40; VERSION main 1'
Invalid version format (non-numeric data) at -e line 1.

Those should both be treated the same way, as $VERSION stringifies and
nummifies the same way in both cases.

NOTABUG. The only reason why the version code might get an exponential
number is in the case of a bare number in the source file (typically
something very small) that Perl's default stringification would render
in exponential notation. There is code to explicitly sprintf() that
value at high precision prior to parsing. This is not a common situation.

Versions are not arbitrary​: they are intended to be useful values that
are monotonically increasing in size. We should not support someone
trying to use irrational numbers or huge/tiny floating point numbers as
Version initializers. Floating point numbers are, by definition, not
100% representational in binary notation (though with 64bit NV's, it is
a huge address space). Anyone wanting to have such a high level of
accuracy should be quoting their initializer, rather than relying on
Perl to DTRT with bare numbers as floating point.

The RT System itself - Status changed from 'new' to 'open'

From @dcollinsn

On Sun Jun 17 15​:46​:40 2012, jpeacock wrote​:

NOTABUG. The only reason why the version code might get an exponential
number is in the case of a bare number in the source file (typically
something very small) that Perl's default stringification would render
in exponential notation. There is code to explicitly sprintf() that
value at high precision prior to parsing. This is not a common situation.

Versions are not arbitrary​: they are intended to be useful values that
are monotonically increasing in size. We should not support someone
trying to use irrational numbers or huge/tiny floating point numbers as
Version initializers. Floating point numbers are, by definition, not
100% representational in binary notation (though with 64bit NV's, it is
a huge address space). Anyone wanting to have such a high level of
accuracy should be quoting their initializer, rather than relying on
Perl to DTRT with bare numbers as floating point.

Any comment on John's response, above?

--
Respectfully,
Dan Collins

From [Unknown Contact. See original ticket]

On Sun Jun 17 15​:46​:40 2012, jpeacock wrote​:

NOTABUG. The only reason why the version code might get an exponential
number is in the case of a bare number in the source file (typically
something very small) that Perl's default stringification would render
in exponential notation. There is code to explicitly sprintf() that
value at high precision prior to parsing. This is not a common situation.

Versions are not arbitrary​: they are intended to be useful values that
are monotonically increasing in size. We should not support someone
trying to use irrational numbers or huge/tiny floating point numbers as
Version initializers. Floating point numbers are, by definition, not
100% representational in binary notation (though with 64bit NV's, it is
a huge address space). Anyone wanting to have such a high level of
accuracy should be quoting their initializer, rather than relying on
Perl to DTRT with bare numbers as floating point.

Any comment on John's response, above?

--
Respectfully,
Dan Collins

From @Leont

On Tue, Sep 20, 2016 at 10​:04 PM, Dan Collins via RT <
perlbug-comment@​perl.org> wrote​:

On Sun Jun 17 15​:46​:40 2012, jpeacock wrote​:

NOTABUG. The only reason why the version code might get an exponential
number is in the case of a bare number in the source file (typically
something very small) that Perl's default stringification would render
in exponential notation. There is code to explicitly sprintf() that
value at high precision prior to parsing. This is not a common
situation.

Versions are not arbitrary​: they are intended to be useful values that
are monotonically increasing in size. We should not support someone
trying to use irrational numbers or huge/tiny floating point numbers as
Version initializers. Floating point numbers are, by definition, not
100% representational in binary notation (though with 64bit NV's, it is
a huge address space). Anyone wanting to have such a high level of
accuracy should be quoting their initializer, rather than relying on
Perl to DTRT with bare numbers as floating point.

Any comment on John's response, above?

If version worked as FC just proposed, something as simple as «$VERSION =
0.000001;» would suddenly break. It would be more consistent but less
useful. It's better to think of versions as neither strings nor numbers,
but something of their own.

Leon