On 06/19/2014 06:06 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
...
In the real world you work with typical programs that run on finite
resources guided by heuristics. There is no proof that you cannot have
@safe.
I assume you mean @safe === memory safety.
So leave
On 06/19/2014 09:06 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 19 June 2014 at 18:25:00 UTC, Tobias Pankrath wrote:
It's not. Since the resources to verify a property are limited, too.
If I need to enumerate all possible program states, there will always
On 06/19/2014 10:39 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 19 June 2014 at 20:26:27 UTC, Timon Gehr wrote:
...
No, your line of reasoning is flawed. The amount of resources is not a
constant. You must prove that memory safety holds for
I have not set
On 06/19/2014 11:28 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
But we aren't talking machine language, we are talking D.
This part is spot on.
On 06/19/2014 10:29 PM, Dicebot wrote:
+1
I have always wondered why `inout` is limited to const when problem is
almost identical with all other restrictive attributes.
I have furthermore always wondered why there can always only be one
`inout' wildcard in scope. This is not the best existing
On 06/20/2014 09:22 PM, Brian Schott wrote:
http://wiki.dlang.org/DIP64
Attributes in D have two problems:
1. There are too many of them and declarations are getting too verbose
2. New attributes use @ and the old ones do not.
I've created a DIP to address these issues.
Why not make the
On 06/21/2014 12:20 AM, Walter Bright wrote:
http://developers.slashdot.org/story/14/06/20/1824226/overeager-compilers-can-open-security-holes-in-your-code
This is an opportunity for D to define the spec in such away as to
preclude the bad optimizations while keeping the good ones. Any ideas?
On 06/26/2014 11:35 AM, Walter Bright wrote:
On 6/26/2014 2:19 AM, bearophile wrote:
One kind of problem left is to avoid stack overflows.
In general, stack overflow checking at compile time is the halting
problem.
That is irrelevant to his point because he is not suggesting to solve
the
On 06/26/2014 10:29 PM, Walter Bright wrote:
On 6/26/2014 2:52 AM, Timon Gehr wrote:
On 06/26/2014 11:35 AM, Walter Bright wrote:
On 6/26/2014 2:19 AM, bearophile wrote:
One kind of problem left is to avoid stack overflows.
In general, stack overflow checking at compile time is the halting
On 06/27/2014 01:47 AM, Andrei Alexandrescu wrote:
On 6/26/14, 4:16 PM, Timon Gehr wrote:
...
You can say out of scope or not a priority or this should be
realized in third-party tool support but not it is impossible.
I also seem to reckon Walter is in the other extreme (he asserts it
can't
On 06/28/2014 06:11 PM, Mason McGill wrote:
On Saturday, 28 June 2014 at 09:15:29 UTC, Dicebot wrote:
On Friday, 27 June 2014 at 22:01:21 UTC, Mason McGill wrote:
I like DIP54 and I think the work on fixing tuples is awesome, but I
have 1 nit-picky question: why is it called
On 06/28/2014 09:40 PM, deadalnix wrote:
On Friday, 27 June 2014 at 05:45:19 UTC, H. S. Teoh via Digitalmars-d
wrote:
We'd make a step forward when we stop calling type tuples type tuples.
They are not tuples, and do not contain (only) types.
I agree, but that's what they're called in the
On 06/29/2014 12:42 AM, safety0ff wrote:
On Saturday, 28 June 2014 at 21:51:17 UTC, Ary Borenszweig wrote:
I think it's common:
http://julia.readthedocs.org/en/latest/manual/types/#tuple-types
Actually, that section is about normal tuples, there is no distinction
between normal tuples and
On 06/29/2014 02:40 AM, Walter Bright wrote:
On 6/28/2014 3:33 AM, Russel Winder via Digitalmars-d wrote:
...
So D should perhaps make a breaking change and have types int32, int64,
float32, float64, float80, and get away from the vagaries of bizarre
type relationships with hardware?
D's spec
On 06/29/2014 02:42 AM, Walter Bright wrote:
On 6/28/2014 6:49 AM, Andrei Alexandrescu wrote:
The only problem is/would be when the language forces one choice over
the other.
Both options of maximum performance and maximum precision should be
handily
accessible to D users.
That's a much more
On 07/01/2014 02:35 PM, Sebastian Graf wrote:
Actually, like bearophile pointed out, it's not that Option is a
range, but that ranges and Option are monads,
Option 'is' a range as much as it 'is'* a monad.
e.g. mappable and flattenable.
i.e. empty, front, popFront have conforming
On 07/03/2014 05:16 AM, Wanderer wrote:
On Wednesday, 2 July 2014 at 17:21:36 UTC, Jonathan M Davis via
Digitalmars-d wrote:
By not putting these functions on Object, it allows them to have whatever
attributes they need when declared in derived types. Without that,
we're stuck
That's not the
On 07/05/2014 07:07 PM, Daniel Murphy wrote:
Wanderer wrote in message news:jbvbufgyhbjrkpukr...@forum.dlang.org...
For pair of integers, you can use long and sort an array of longs.
Awesome, now your sort order depends on processor endianness!
?
k=i32|j, i=k32, j=k(1L32)-1.
On 07/06/2014 12:39 AM, bearophile wrote:
Look at this Issue https://d.puremagic.com/issues/show_bug.cgi?id=3934
for some humorous examples fit more for the Monty Python and the Flying
Circus than a serious language.
While there are some oddities there, many (most?) reports in that issue
are
On 07/06/2014 05:19 AM, Wanderer wrote:
On Saturday, 5 July 2014 at 16:03:17 UTC, Dmitry Olshansky wrote:
...
Pointers are perfectly fine as long as there is no pointer arithmetic.
Wrong. Merely holding a pointer (i.e. a physical address) is unsafe
already. Non-deep serialization, or any
Please don't under-quote, thanks.
Pointers are perfectly fine as long as there is no pointer arithmetic.
Wrong. Merely holding a pointer (i.e. a physical address) is unsafe already.
Non-deep serialization, or any other preservation of such a struct and GC
is unable to keep the track of
On 07/08/2014 11:22 PM, Walter Bright wrote:
...
3. 'ref' means 'borrowed', to use Rust's terminology
We're almost there with this. This means better escape analysis, too.
...
What makes you think that 'ref' is a good match for this functionality,
and how are we almost there with this?
On 07/09/2014 09:50 PM, Walter Bright wrote:
On 7/9/2014 7:37 AM, Timon Gehr wrote:
On 07/08/2014 11:22 PM, Walter Bright wrote:
3. 'ref' means 'borrowed', to use Rust's terminology
We're almost there with this. This means better escape analysis, too.
What makes you think that 'ref' is a good
On 07/10/2014 02:39 AM, Walter Bright wrote:
On 7/9/2014 5:24 PM, Timon Gehr wrote:
On 07/09/2014 09:50 PM, Walter Bright wrote:
On 7/9/2014 7:37 AM, Timon Gehr wrote:
On 07/08/2014 11:22 PM, Walter Bright wrote:
3. 'ref' means 'borrowed', to use Rust's terminology
We're almost there with
On 07/10/2014 07:41 AM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Jul 10, 2014 at 05:12:23AM +0200, Timon Gehr via Digitalmars-d wrote:
[...]
- Lifetime parameters. (it's more future-proof if they are not
introduced by simple identifiers.)
Eg.: void foo[lifetime lt](int x
On 07/10/2014 08:59 AM, Walter Bright wrote:
On 7/9/2014 8:12 PM, Timon Gehr wrote:
3. have a design and a plan that gets there
There's no law that says D refs must be exactly like Rust borrowed. We
can come up with a design that works best for D. D != Rust. Do you have
a design in mind?
...
On 07/10/2014 10:10 PM, Marc Schütz schue...@gmx.net wrote:
...
Instead of lifetime intersections with `` (I believe Timon proposed
that in the original thread)
I didn't. I suggested that _some_ suitable syntax might need to be found. :)
The root cause of the problem here is the call to
On 07/10/2014 10:41 PM, Walter Bright wrote:
On 7/10/2014 11:53 AM, Timon Gehr wrote:
Are you talking about the concept, the examples, or just the last
example? What
makes it seem complicated?
I can't imagine users going to the bother of typing all that,
As explicitly stated this was just
On 07/10/2014 08:12 PM, Jonathan Marler wrote:
So what do people think?
How do you make sure there is at most one thread of each kind?
On 07/12/2014 05:56 PM, Israel Rodriguez wrote:
On Monday, 7 July 2014 at 15:33:06 UTC, bearophile wrote:
From the blog post:
However, the language itself feels a bit old and a bit too much like
C++. That's not strange considering its age, but you can’t help
thinking that time has left D a
On 07/13/2014 01:13 PM, fra wrote:
...
Macros are an aberration that allow code writers to create code
that is plan impossible to understand and mantain.
If that is what they want to do, that is what they are going to do.
They don't need macros for that.
Mixins can give you pretty much the
On 07/13/2014 12:45 PM, Dicebot wrote:
On Sunday, 13 July 2014 at 10:19:26 UTC, Jacob Carlborg wrote:
On 2014-07-12 01:02, Dicebot wrote:
Whatever is ideal solution, we better focus on something practical that
can be realistically added to the language within current priorities
(stability,
On 07/13/2014 02:44 PM, Dicebot wrote:
On Sunday, 13 July 2014 at 12:33:21 UTC, Timon Gehr wrote:
Yes I know and likely would have preferred that approach if we were
speaking about designing brand new language. But right now we already
have string mixins
They are not a great liability. They
On 07/13/2014 04:09 PM, Jacob Carlborg wrote:
On 2014-07-13 14:33, Timon Gehr wrote:
They are not a great liability. They are a simple feature. They take up
less than 200 lines of code in my D frontend implementation, _together_
with template mixins.
Do you have the source for your frontend
On 07/13/2014 05:24 PM, Dicebot wrote:
On Sunday, 13 July 2014 at 15:17:27 UTC, Timon Gehr wrote:
(Just to be sure: I was talking about string mixins, not macros, I
haven't implemented macros.)
Currently it isn't. It isn't really in a state where I'd like to see
it released. There are some
On 07/14/2014 03:25 AM, fra wrote:
On Sunday, 13 July 2014 at 20:56:31 UTC, Ary Borenszweig wrote:
On 7/13/14, 8:13 AM, fra wrote:
Macros are an aberration that allow code writers to create code
that is plan impossible to understand and mantain. Mixins can
give you pretty much the same amoun
On 07/14/2014 11:55 AM, Dicebot wrote:
I must admit D is far from perfect in that regard because operator
overloading is still not limited enough
There is no real point in limiting it at all. It is just a matter of
naming your functions properly.
auto subtract(int a, int b){ return a+b; }
On 07/14/2014 05:29 PM, Dicebot wrote:
On Monday, 14 July 2014 at 15:13:21 UTC, Timon Gehr wrote:
On 07/14/2014 11:55 AM, Dicebot wrote:
I must admit D is far from perfect in that regard because operator
overloading is still not limited enough
There is no real point in limiting it at all. It
On 07/16/2014 01:22 PM, Remo wrote:
On Monday, 14 July 2014 at 23:43:57 UTC, H. S. Teoh via Digitalmars-d
wrote:
On Mon, Jul 14, 2014 at 11:22:53PM +, John Carter via
Digitalmars-d wrote:
[...]
Any other good blog posts / social media comments / pointers I can
digest and use?
This one
On 07/17/2014 12:18 AM, Walter Bright wrote:
On 7/16/2014 2:26 PM, Gary Willoughby wrote:
What is the current situation of integer overflow and underflow?
https://github.com/D-Programming-Language/druntime/pull/839
(His question was whether there is wrap-around behaviour for signed
types,
On 07/18/2014 12:00 AM, Trass3r wrote:
void foo(int a, int b = a)
{
}
is illegal in C++ because order of evaluation is undefined.
But since D defines the order to be left to right couldn't it also allow
this?
It could, and I think it is an unnecessary limitation that it currently
does not.
On 07/17/2014 04:01 PM, Byron Heads wrote:
A Volatile(T) in stdlib seems to make a lot of sense, I am also wondering
if the implementation of shared should be done the same way (if it does
already then ignore), just use the compile to enforce shared and have it
rewrite it as Shared(T).
...
On 07/17/2014 05:58 PM, Andrei Alexandrescu wrote:
* volatile has been one of the most awkward parts of the C and C++
specifications. If we're to learn of anything about it, it's we must
stay away from it. It is extremely heavy for what it provides.
...
==
I think an approach
On 07/18/2014 08:37 PM, Walter Bright wrote:
On 7/18/2014 11:06 AM, Timon Gehr wrote:
On 07/17/2014 05:58 PM, Andrei Alexandrescu wrote:
* volatile has been one of the most awkward parts of the C and C++
specifications. If we're to learn of anything about it, it's we must
stay away from it.
On 07/17/2014 06:27 PM, Tero wrote:
Just watched Don's DConf 2014 talk where he said D has to be ruthless about
memory inefficiency. Here's one thing that I think could help avoid
unnecessary garbage: built-in syntax for this:
import core.stdc.stdlib : alloca;
ubyte[] buffer = (cast(ubyte*)
On 07/18/2014 09:23 PM, Meta wrote:
On Friday, 18 July 2014 at 17:59:05 UTC, Brad Anderson wrote:
On Friday, 18 July 2014 at 08:48:08 UTC, Walter Bright wrote:
[...]
Since there are a lot of existing lazy algorithms in Phobos that do
not follow this naming convention, either the convention is
On 07/19/2014 02:07 AM, Walter Bright wrote:
On 7/18/2014 4:58 PM, Timon Gehr wrote:
On 07/18/2014 08:37 PM, Walter Bright wrote:
That doesn't change the heavy effort in the semantic front end
What does this mean in detail? Is it just about the unfortunate AST
representation chosen or are
On 07/20/2014 10:50 PM, Walter Bright wrote:
On 7/20/2014 3:27 AM, Dmitry Olshansky wrote:
Functional programming is full of simple recursion and it would be
nice not to
stack overflow in debug builds.
Traditional FP languages don't have loops, and so must do recursion.
Uh...
D has loops,
On 07/21/2014 06:40 AM, Andrei Alexandrescu wrote:
On 7/20/14, 8:15 PM, Timon Gehr wrote:
On 07/20/2014 10:50 PM, Walter Bright wrote:
On 7/20/2014 3:27 AM, Dmitry Olshansky wrote:
Functional programming is full of simple recursion and it would be
nice not to
stack overflow in debug builds.
On 07/21/2014 06:56 AM, Walter Bright wrote:
On 7/20/2014 8:15 PM, Timon Gehr wrote:
On 07/20/2014 10:50 PM, Walter Bright wrote:
On 7/20/2014 3:27 AM, Dmitry Olshansky wrote:
Functional programming is full of simple recursion and it would be
nice not to
stack overflow in debug builds.
On 07/22/2014 12:10 AM, bearophile wrote:
Except for the fact that it has bounded stack size which is a useful
property by itself and not only for tailrecursive functions.
Yes, that's why I have said that a @continuation is a more general
solution than @tailrec.
Bye,
bearophile
On 07/22/2014 05:02 AM, Walter Bright wrote:
On 7/21/2014 3:25 PM, Timon Gehr wrote:
The example just uses the ST Monad which is quite similar to weakly pure
statements in D.
D doesn't have weakly pure statements - it has weakly pure functions.
The type checker distinguishes between
On 07/22/2014 05:49 PM, Andrei Alexandrescu wrote:
On 7/21/14, 3:22 PM, Timon Gehr wrote:
On 07/21/2014 06:40 AM, Andrei Alexandrescu wrote:
On 7/20/14, 8:15 PM, Timon Gehr wrote:
On 07/20/2014 10:50 PM, Walter Bright wrote:
...
D has loops, even in pure functions,
So does Haskell.
import
On 07/22/2014 08:34 PM, Walter Bright wrote:
On 7/20/2014 8:15 PM, Timon Gehr wrote:
So does Haskell.
import Control.Monad
import Control.Monad.ST
import Data.STRef
factorial :: Integer - Integer
factorial n = runST $ do
r - newSTRef 1
forM_ [1..n] $ \i-
modifySTRef r (*i)
On 07/22/2014 09:42 PM, Walter Bright wrote:
On overall I prefer D over Haskell, but if you want to criticize
Haskell you
need much much better arguments and way bigger cannons :-)
The point was not at all to criticize Haskell. The point was that D does
not need tail recursion because D
On 07/22/2014 11:23 PM, Timon Gehr wrote:
Looping is not the main reason for supporting tail calls.
(In D!)
On 07/23/2014 12:14 AM, Walter Bright wrote:
Sure, that part of the discussion grew out of the claim that there are
no
loops there.
Bending a language over backwards
Not what happened.
to be pedantic
Being pedantic is important enough.
is pointless for this discussion.
If one
On 07/23/2014 06:45 PM, H. S. Teoh via Digitalmars-d wrote:
This morning, I discovered this major WAT in D:
struct S {
int x;
int y;
int opCmp(S s) {
return x - s.x; // compare only x
}
}
...
Not even transitive!
void main() {
On 07/25/2014 11:34 PM, Walter Bright wrote:
On 7/25/2014 2:53 AM, Jakob Ovrum wrote:
On Friday, 25 July 2014 at 09:39:23 UTC, Walter Bright wrote:
That can be special cased, too.
Seriously? Where does it end?
catch(MyTemplatedException!true) {
}
That one can't be special cased in the
On 07/28/2014 09:32 PM, Brian Schott wrote:
On Monday, 28 July 2014 at 19:12:49 UTC, Timon Gehr wrote:
I'd suggest to just special case the general thing, or not add any
special cases at all.
catch(Type)
^~
I.e. use lookahead to determine whether something that looks like a
type
On 07/28/2014 10:23 PM, Brian Schott wrote:
On Monday, 28 July 2014 at 20:14:24 UTC, Timon Gehr wrote:
foreach(i;0..n){
// ...
}
(x).foo();
try{
// ...
}catch(Exception e){
return e;
}
(new Exception(hi)).msg.writeln;
I don't see how these are ambiguous.
Both are ambiguous for
On 07/27/2014 04:39 AM, Andrei Alexandrescu wrote:
On 7/26/14, 6:30 PM, w0rp wrote:
The std.algortihm documentation doesn't look good, and I don't have any
good ideas for it.
I find std.algorithm among the best documented libraries out there! I
^~~
This actually
On 07/29/2014 03:07 AM, Walter Bright wrote:
On 7/28/2014 1:49 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
You might want to assert() that you have enough headroom in a statically
allocated buffer when testing. Say you assert that the buffer is never
more than
50% full
On 07/29/2014 08:54 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 29 July 2014 at 10:40:33 UTC, John Colvin wrote:
In a correct program (a necessary but not sufficient condition for
which is to not violate it's asserts) it is the same.
Define
On 07/29/2014 10:52 PM, Walter Bright wrote:
On 7/29/2014 1:07 PM, Timon Gehr wrote:
On 07/29/2014 03:07 AM, Walter Bright wrote:
On 7/28/2014 1:49 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
You might want to assert() that you have enough headroom in a
statically
On 07/29/2014 11:08 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
The best you can hope to have is partial correctness. Even with a system
for formal verification.
Well, why would this be true?
On 07/30/2014 02:48 AM, Walter Bright wrote:
On 7/29/2014 3:02 PM, Timon Gehr wrote:
They are dual concepts. Assert demands a property to hold, assume
provides a
property that holds.
A distinction without a difference.
Wtf.
(Imagine you are arguing with someone who keeps claiming that the
On 07/30/2014 09:22 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 29 July 2014 at 22:07:42 UTC, Timon Gehr wrote:
On 07/29/2014 11:08 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
The best you can hope to
On 07/30/2014 05:33 PM, Daniel Murphy wrote:
Timon Gehr wrote in message news:lrb2o9$314b$1...@digitalmars.com...
Because there is no way you can prove say OpenGL drivers to be correct.
They are a black box provided by the execution environment.
I see. (Though I secretly still dare to hope
On 07/30/2014 05:04 PM, Andrei Alexandrescu wrote:
On 7/30/14, 4:56 AM, Daniel Murphy wrote:
Artur Skawina via Digitalmars-d wrote in message
news:mailman.217.1406713015.16021.digitalmar...@puremagic.com...
`assert` is for *verifying* assumptions. It must not allow them
to leak/escape.
On 07/30/2014 06:30 PM, Daniel Murphy wrote:
Timon Gehr wrote in message news:lrb5pd$1uv$1...@digitalmars.com...
On a more serious note, are you trying to argue that there are no
pragmatic differences in software quality based on the obvious fact
that the system running the software is
On 07/30/2014 04:11 PM, Daniel Murphy wrote:
Artur Skawina via Digitalmars-d wrote in message
news:mailman.227.1406728603.16021.digitalmar...@puremagic.com...
D - the language that redefines commonly used and universally
understood terms and concepts?
Yes, see pure for another example. D -
On 07/30/2014 05:28 PM, H. S. Teoh via Digitalmars-d wrote:
Yeah, I think this hair-splitting between assume and assert is ... pure
hair-splitting.
Which is pure name-calling.
On 07/30/2014 06:43 PM, Daniel Murphy wrote:
John Colvin wrote in message
news:mmnpehpddzkduycyd...@forum.dlang.org...
So what is the recommended way of inserting a check of the sort that
Ola would like?
debug enforce(expr);
perhaps? Seeing as that statement is completely missing outside of
On 07/30/2014 07:00 PM, Timon Gehr wrote:
...
Isn't this also true for assert statements?
s/statement/expression
On 07/30/2014 05:45 PM, Tofu Ninja wrote:
On Wednesday, 30 July 2014 at 15:24:57 UTC, Timon Gehr wrote:
I see. (Though I secretly still dare to hope for verified OpenGL
drivers, or something analogous: it is not completely out of reach
theoretically; the machine can be given a quite precise
On 07/30/2014 06:55 PM, Daniel Murphy wrote:
Timon Gehr wrote in message news:lrb6lf$2tf$1...@digitalmars.com...
I mean, we have at least:
list
You forgot 'float', which has nothing to do with levitation.
...
:D
This is all true, yet we have to pick names for things. We could call
D's
On 07/30/2014 07:15 PM, Daniel Murphy wrote:
Timon Gehr wrote in message news:lrb86k$428$1...@digitalmars.com...
On 07/30/2014 05:28 PM, H. S. Teoh via Digitalmars-d wrote:
Yeah, I think this hair-splitting between assume and assert is ... pure
hair-splitting.
Which is pure name-calling.
On 07/30/2014 07:46 PM, Andrei Alexandrescu wrote:
On 7/30/14, 9:20 AM, Walter Bright wrote:
On 7/30/2014 7:51 AM, Andrei Alexandrescu wrote:
Also, it's unclear to me what the optimizer would be supposed to do
if an
assumption turns out to be false.
The program is no longer valid at that
On 07/30/2014 07:59 PM, Daniel Murphy wrote:
Timon Gehr wrote in message news:lrbb2a$6du$1...@digitalmars.com...
The second issue is that the statement above tries to look like it is
tautological by seeming to express both factual information and an
opinion at the same time.
I prefer to
On 07/30/2014 08:06 PM, John Colvin wrote:
P.S. What about version(assert)? Could the optimiser work with this:
if(x 7) x++;
version(assert) auto testResult = x;
assert(x = 7);
No, version(assert) is just about doing introspection on the
compiler's configuration. In release mode that
On 07/30/2014 07:56 PM, Andrei Alexandrescu wrote:
On 7/30/14, 9:31 AM, Timon Gehr wrote:
On 07/30/2014 05:04 PM, Andrei Alexandrescu wrote:
On 7/30/14, 4:56 AM, Daniel Murphy wrote:
Artur Skawina via Digitalmars-d wrote in message
On 07/30/2014 08:46 PM, H. S. Teoh via Digitalmars-d wrote:
I can't think of a real-life scenario where you'd want to distinguish
between the two kinds of optimizations in (2).
That was never up to debate and that distinction is indeed rather pointless.
On 07/30/2014 08:39 PM, Daniel Murphy wrote:
Wyatt wrote in message news:duoyilszsehayiffp...@forum.dlang.org...
Something (possibly the thing where For fastest executables, compile
with the -O -release -inline -boundscheck=off is standard advice to
anyone asking about performance) tells me
On 07/30/2014 09:16 PM, H. S. Teoh via Digitalmars-d wrote:
On Wed, Jul 30, 2014 at 07:09:41PM +, via Digitalmars-d wrote:
On Wednesday, 30 July 2014 at 18:25:43 UTC, H. S. Teoh via Digitalmars-d
wrote:
If you want the check to always be there, use enforce, not assert.
Doesn't help:
On 07/30/2014 10:39 PM, Walter Bright wrote:
On 7/30/2014 2:12 AM, bearophile wrote:
Info about assume in Microsoft C++:
http://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx
Note that document shows how assert
Some random ASSERT macro with custom behaviour. That article shows a few
On 07/30/2014 11:15 PM, Walter Bright wrote:
On 7/30/2014 1:45 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
Can you please read the Hoare article form 1969? This is getting
really annoying.
Ironically, your wikipedia entry on Hoare references
On 07/30/2014 11:28 PM, Walter Bright wrote:
On 7/30/2014 1:56 PM, David Bregman wrote:
Can you please address the fact that assume is not @safe?
How do you propose to
preserve memory safety in release mode if you remove runtime checks
for asserts
but still assume the condition for codegen?
On 07/30/2014 10:55 PM, Andrei Alexandrescu wrote:
On 7/30/14, 11:31 AM, Timon Gehr wrote:
On 07/30/2014 07:56 PM, Andrei Alexandrescu wrote:
On 7/30/14, 9:31 AM, Timon Gehr wrote:
'lazy', which denotes pass by name instead of pass by need.
It's not pass by name.
...
How so? Is it about
On 07/30/2014 11:42 PM, Walter Bright wrote:
On 7/30/2014 2:34 PM, Timon Gehr wrote:
He understands that and notes that this contradicts the promise of @safe.
No, it does not. @safe never promises that all your asserts are correct.
@safe's promise is one of memory safety,
Indeed it is.
On 07/30/2014 11:39 PM, Walter Bright wrote:
On 7/30/2014 2:21 PM, Timon Gehr wrote:
Because the compiler does not seem know that 'assert' never returns,
they shove
in an __assume after it.
The critical bit of misunderstanding here is the C standard *requires*
that assert be implemented as a
On 07/31/2014 12:17 AM, Andrei Alexandrescu wrote:
On 7/30/14, 3:06 PM, Timon Gehr wrote:
On 07/30/2014 10:55 PM, Andrei Alexandrescu wrote:
On 7/30/14, 11:31 AM, Timon Gehr wrote:
On 07/30/2014 07:56 PM, Andrei Alexandrescu wrote:
...
case for assume to the language creators.
I think
On 07/31/2014 12:39 AM, Walter Bright wrote:
On 7/30/2014 2:30 PM, Timon Gehr wrote:
Did you read the article?
http://en.wikipedia.org/wiki/Assertion_%28computing%29#Disabling_assertions
'[...] disabling assertion checking can mean that a program that would
have
aborted will continue to run.
On 07/31/2014 12:55 AM, bearophile wrote:
So now you now have a safe function that is unsafe.
Even in debug builds.
Bye,
bearophile
Why?
On 07/31/2014 09:03 PM, Walter Bright wrote:
On 7/31/2014 3:24 AM, ponce wrote:
On Thursday, 31 July 2014 at 09:13:53 UTC, Walter Bright wrote:
On 7/31/2014 1:23 AM, Daniel Murphy wrote:
Walter Bright wrote in message news:lrbpvj$mih$1...@digitalmars.com...
5. assert(0); is equivalent to a
On 07/31/2014 08:58 PM, Walter Bright wrote:
On 7/31/2014 4:28 AM, David Bregman wrote:
Sigh. Of course you can assume the condition after a runtime check has
been
inserted. You just showed that
assert(x); assume(x);
is semantically equivalent to
assert(x);
as long as the runtime check is
On 07/31/2014 09:37 PM, Jonathan M Davis wrote:
On Thursday, 31 July 2014 at 18:43:49 UTC, Ary Borenszweig wrote:
On 7/31/14, 4:37 AM, Walter Bright wrote:
On 7/30/2014 4:05 PM, Ary Borenszweig wrote:
On 7/30/14, 7:01 PM, Walter Bright wrote:
I'd like to sum up my position and intent on all
On 07/31/2014 10:33 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Jul 31, 2014 at 05:17:13PM -0300, Ary Borenszweig via Digitalmars-d
wrote:
On 7/31/14, 4:54 PM, H. S. Teoh via Digitalmars-d wrote:
[...]
But doesn't that just mean that you shouldn't use -release, period?
AFAIK, the only
On 07/31/2014 09:54 PM, Jonathan M Davis wrote:
On Thursday, 31 July 2014 at 19:11:55 UTC, Timon Gehr wrote:
On 07/31/2014 09:03 PM, Walter Bright wrote:
It means if the control flow does actually get there, a HALT is
executed.
And assuming control flow does not actually get there?
Then
On 07/31/2014 11:01 PM, ponce wrote:
Could you expand on what you consider input? For example, if a
function has an in contract that validates input parameters, is
the determination that a parameter is invalid a program bug or
simply invalid input? ...
The assertions in an 'in' contracts are
101 - 200 of 1775 matches
Mail list logo
