One issue that should ideally be resolved before D2 is finalized that I meant
to bring up here a long time ago is how to handle pure and nothrow in generic
functions. For example:
T max(T)(T lhs, T rhs) {
return (lhs > rhs) ? lhs : rhs;
}
Obviously, if T is an int, max can be pure nothrow.
On Sun, 22 Nov 2009 20:34:21 +0100, dsimcha wrote:
One issue that should ideally be resolved before D2 is finalized that I
meant
to bring up here a long time ago is how to handle pure and nothrow in
generic
functions. For example:
T max(T)(T lhs, T rhs) {
return (lhs > rhs) ? lhs : rh
dsimcha wrote:
One issue that should ideally be resolved before D2 is finalized that I meant
to bring up here a long time ago is how to handle pure and nothrow in generic
functions. For example:
T max(T)(T lhs, T rhs) {
return (lhs > rhs) ? lhs : rhs;
}
Obviously, if T is an int, max can b
== Quote from Don (nos...@nospam.com)'s article
> dsimcha wrote:
> > One issue that should ideally be resolved before D2 is finalized that I
> > meant
> > to bring up here a long time ago is how to handle pure and nothrow in
> > generic
> > functions. For example:
> >
> > T max(T)(T lhs, T rhs)
dsimcha wrote:
I would say that @safe doesn't make much sense. What if you're implementing
your
comparison function using memcmp() or something else that involves a bunch of
pointers? If you pass memcmp() invalid parameters, it can segfault, and would
therefore have to be marked as unsafe, mea
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> dsimcha wrote:
> > I would say that @safe doesn't make much sense. What if you're
> > implementing your
> > comparison function using memcmp() or something else that involves a bunch
> > of
> > pointers? If you pass memcmp() i
dsimcha wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
dsimcha wrote:
I would say that @safe doesn't make much sense. What if you're implementing
your
comparison function using memcmp() or something else that involves a bunch of
pointers? If you pass memcmp() inval
dsimcha wrote:
I think you misunderstood the argument. memcmp() could be @trusted if functions
only need to be safe when passed valid parameters, though I don't necessarily
agree that this makes sense. I was thinking memcmp() shouldn't even be marked
@trusted because it's so easy to invoke unde
Don wrote:
It seems to me that one of the most important features of SafeD is that
whenever a @safe function invokes a function, it does so only with valid
parameters. The problem with memcmp() is that the required relationship
between the parameters is complicated, and can't be determined
sta
Hello Walter,
there's no
way that an @safe function can guarantee it sends memcmp() arguments
that will work safely with memcmp().
I think that's backwards. There's no way memcmp can be sure it's arguments
are safe just because it's being called from a @safe function.
OTOH, if a @trusted fu
Walter Bright wrote:
dsimcha wrote:
I think you misunderstood the argument. memcmp() could be @trusted if
functions
only need to be safe when passed valid parameters, though I don't
necessarily
agree that this makes sense. I was thinking memcmp() shouldn't even
be marked
@trusted because it'
Andrei Alexandrescu wrote:
Walter Bright wrote:
dsimcha wrote:
I think you misunderstood the argument. memcmp() could be @trusted
if functions
only need to be safe when passed valid parameters, though I don't
necessarily
agree that this makes sense. I was thinking memcmp() shouldn't even
be
== Quote from Don (nos...@nospam.com)'s article
> Andrei Alexandrescu wrote:
> > Walter Bright wrote:
> >> dsimcha wrote:
> >>> I think you misunderstood the argument. memcmp() could be @trusted
> >>> if functions
> >>> only need to be safe when passed valid parameters, though I don't
> >>> necess
On Fri, 27 Nov 2009 23:51:44 +0300, Andrei Alexandrescu
wrote:
Walter Bright wrote:
dsimcha wrote:
I think you misunderstood the argument. memcmp() could be @trusted if
functions
only need to be safe when passed valid parameters, though I don't
necessarily
agree that this makes sense.
On Sat, 28 Nov 2009 00:20:47 +0300, dsimcha wrote:
== Quote from Don (nos...@nospam.com)'s article
Andrei Alexandrescu wrote:
> Walter Bright wrote:
>> dsimcha wrote:
>>> I think you misunderstood the argument. memcmp() could be @trusted
>>> if functions
>>> only need to be safe when passed v
dsimcha:
> Isn't overflowing a signed int undefined behavior?
Yes, it can be.
>If so, how would we eliminate undefined behavior without very expensive
>runtime checks?<
I have explained LLVM devs how to speed-up some of those runtime checks.
Do you exactly know how much expensive they are, in
Denis Koroskin:
> I don't think integer overflow could be considered an undefined behavior.
> It's pretty much expected that uint.max + 1 == 0.
Computers are (mostly) deterministic, so in a certain sense everything they do
can be expected :-)
But sometimes the programmer "forgets" or doesn't t
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
> On Sat, 28 Nov 2009 00:20:47 +0300, dsimcha wrote:
> > == Quote from Don (nos...@nospam.com)'s article
> >> Andrei Alexandrescu wrote:
> >> > Walter Bright wrote:
> >> >> dsimcha wrote:
> >> >>> I think you misunderstood the argument. m
Don wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
dsimcha wrote:
I think you misunderstood the argument. memcmp() could be @trusted
if functions
only need to be safe when passed valid parameters, though I don't
necessarily
agree that this makes sense. I was thinking memcmp() should
Denis Koroskin wrote:
On Fri, 27 Nov 2009 23:51:44 +0300, Andrei Alexandrescu
wrote:
Walter Bright wrote:
dsimcha wrote:
I think you misunderstood the argument. memcmp() could be @trusted
if functions
only need to be safe when passed valid parameters, though I don't
necessarily
agree that
dsimcha wrote:
Quick question about the eliminating undefined behavior thing: Isn't
overflowing
a signed int undefined behavior?
No. On every 2's complement machine I've ever heard of, the behavior is
defined and the same.
Andrei Alexandrescu wrote:
b) incorrect addresses within the application, erroneous result returned
I think it would be implementation-defined behavior - in case (b) memcmp
would return an implementation-defined value but still defined.
How could it?
dsimcha wrote:
What about int.max + 1? I specifically mentioned **signed** integers because,
IIRC overflowing these is undefined in C, but overflowing unsigned is defined.
It's undefined behavior in C because C supports ones-complement
arithmetic. D does not - twos-complement only.
Walter Bright wrote:
Andrei Alexandrescu wrote:
b) incorrect addresses within the application, erroneous result
returned
I think it would be implementation-defined behavior - in case (b)
memcmp would return an implementation-defined value but still defined.
How could it?
The value itself
Andrei Alexandrescu wrote:
Let's not confuse undefined with implementation-defined. I am firmly
convinced that memcmp never falls in the undefined behavior realm. The
behavior is always defined.
Makes sense. But I'd still want to make it not @safe, by using a more
expansive definition of @saf
Walter Bright wrote:
Andrei Alexandrescu wrote:
Let's not confuse undefined with implementation-defined. I am firmly
convinced that memcmp never falls in the undefined behavior realm. The
behavior is always defined.
Makes sense. But I'd still want to make it not @safe, by using a more
expans
Andrei Alexandrescu wrote:
> Denis Koroskin wrote:
>> Points 2 and 3 introduce undefined behavior, which is not allowed in
>> SafeD :p
>
> s/undefined/implementation-defined/
Behavior is only implementation-defined if the implementation actually
defines it. When targeting a specific implementati
I have a feeling that the safeD thing is a bit premature. I'm only
posting this because then I can link to this post next summer, when it's
becoming clear that I was right. Because I'm such a nice guy I won't
even save this link. :P
Noone's ever tried this feature in real code that people a
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
Denis Koroskin wrote:
Points 2 and 3 introduce undefined behavior, which is not allowed in
SafeD :p
s/undefined/implementation-defined/
Behavior is only implementation-defined if the implementation actually
defines it. When targeting a specific
29 matches
Mail list logo
