Patrick (>), Carl (>>), Patrick (>>>):
>> > But yes, I expect that it will be caught as
>> > a compile-time error.
>>
>> And do you agree it's reasonable to expect this of every compiler?
>
> Reasonable to expect it, yes -- but whether or not this rises to the
> level of being a "requirement in th
Carl Mäsak cmasak-at-gmail.com |Perl 6| wrote:
Pm (>):
In Rakudo's case, we just haven't implemented read-only traits
on variables yet.
Goodie. I guessed as much.
But yes, I expect that it will be caught as
a compile-time error.
And do you agree it's reasonable to expect t
On Fri, May 09, 2008 at 05:09:31PM +0200, Carl Mäsak wrote:
> Pm (>):
> > In Rakudo's case, we just haven't implemented read-only traits
> > on variables yet.
>
> Goodie. I guessed as much.
>
> > But yes, I expect that it will be caught as
> > a compile-time error.
>
> And do you agree it's rea
Pm (>):
> In Rakudo's case, we just haven't implemented read-only traits
> on variables yet.
Goodie. I guessed as much.
> But yes, I expect that it will be caught as
> a compile-time error.
And do you agree it's reasonable to expect this of every compiler?
// Carl
On Fri, May 09, 2008 at 03:02:28PM +0200, Carl Mäsak wrote:
> TSa (>):
> > sub bar ($x)
> > {
> >$x = 3; # error, $x is readonly
> >foo($x); # error, could hit rw Str
> > }
>
> By the way, I hope it's possible to make the assignment `$x = 3` to
> the read-only variable $x a compile-time
HaloO,
Carl Mäsak wrote:
By the way, I hope it's possible to make the assignment `$x = 3` to
the read-only variable $x a compile-time error.
I hope so, too. The variable and its read-only constraint
is known at compile time and *not* dependend on the value
inside. How it came in there in the f
TSa (>):
> sub bar ($x)
> {
>$x = 3; # error, $x is readonly
>foo($x); # error, could hit rw Str
> }
By the way, I hope it's possible to make the assignment `$x = 3` to
the read-only variable $x a compile-time error.
In fact, I hope this to such a degree that I would like it to be part
HaloO,
John M. Dlugosz wrote:
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
It's called overload resolution. Perl 6 can't do
that at compile time unless *all* targets are
available as rw and readonly variants.
I don't follow that statement. Can you give an example?
multi sub foo (Int $i
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
It's called overload resolution. Perl 6 can't do
that at compile time unless *all* targets are
available as rw and readonly variants.
I don't follow that statement. Can you give an example?
HaloO,
John M. Dlugosz wrote:
- const int& is preferred over int/int&.
- const int* is preferred over int*.
You mean when in each case both versions are
defined as overloads only the preferred ones
are ever called? C++ is the other way around.
For an int* argument the int* version is preferred
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
Coming back to how C++ handles static overloading. How is
the sort order of (int *), (int &), (int), (const int *),
(const int &), (const int), (int * const) and (const int * const)?
I'm too lazy to look up the details, sorry.
Without looking a
11 matches
Mail list logo
