On 04/28/2016 09:50 AM, Seb wrote:
On Thursday, 28 April 2016 at 13:46:37 UTC, Andrei Alexandrescu wrote:
On 04/27/2016 11:41 PM, Seb wrote:
Just a quick update that #4243 is in and the linting bot is now running.
As I mentioned earlier there are still many trivial flags of Dscanner's
static an
On Thursday, 28 April 2016 at 13:46:37 UTC, Andrei Alexandrescu
wrote:
On 04/27/2016 11:41 PM, Seb wrote:
Just a quick update that #4243 is in and the linting bot is
now running.
As I mentioned earlier there are still many trivial flags of
Dscanner's
static analysis that could be enabled. I mar
On 04/27/2016 11:41 PM, Seb wrote:
Just a quick update that #4243 is in and the linting bot is now running.
As I mentioned earlier there are still many trivial flags of Dscanner's
static analysis that could be enabled. I marked them with "FIXME", so
@anyone feel free to have a look.
Moreover (onc
On Wednesday, 27 April 2016 at 12:38:55 UTC, Andrei Alexandrescu
wrote:
On 04/26/2016 09:36 PM, Seb wrote:
Great news:
1) I submitted a couple of trivial fixes (#4245, #4246, #4247)
2) The Travis bot passes :)
As mentioned I decreased the linting to a minimum, but now we
do have it :)
Future w
On 04/26/2016 09:36 PM, Seb wrote:
On Tuesday, 26 April 2016 at 19:04:44 UTC, Seb wrote:
Hey all,
tl;dr: I want to pull improve Phobos code style for the greater good
of having a bot that automatically checks the coding style. This
should be quite useful for submitters. I hope we all agree that
On Tuesday, 26 April 2016 at 19:04:44 UTC, Seb wrote:
Hey all,
tl;dr: I want to pull improve Phobos code style for the greater
good of having a bot that automatically checks the coding
style. This should be quite useful for submitters. I hope we
all agree that the time spent "nitpicking" is w
I maintain some of the linters at work. One suggestion I'd have
(perhaps you're already on it) is that a linter that can both
detect and prompt to auto-fix the issues is at least an order of
magnitude more useful. People fix things more, people like the
linters more, it avoids the fallacy of tr
On Tuesday, 26 April 2016 at 19:04:44 UTC, Seb wrote:
As expected a styleguide without a automatically enforcing it,
leaks ...
It's not so much a matter of "leaks" - rather, much of DMD,
D-runtime, and Phobos pre-date the style rules, and so never
attempted to follow them in the first place.
Hey all,
tl;dr: I want to pull improve Phobos code style for the greater
good of having a bot that automatically checks the coding style.
This should be quite useful for submitters. I hope we all agree
that the time spent "nitpicking" is wasted, we overlook much (see
below) and we can do bett
On 9/29/2014 6:01 AM, Bruno Medeiros via Digitalmars-d wrote:
I would invite you to buy a *retail copy* of Elder Scrolls 3 : Morrowind
for PC and try playing that. The game did exactly what Walter and you
guys suggested: when an assertion tripped, it would crash straight away
to the desktop, with
On Monday, 29 September 2014 at 13:41:33 UTC, Paulo Pinto wrote:
And the right attitude as consumer is to ask for the money
back, not to wait patiently for the day those bugs eventually
get fixed.
If everyone did that, the quality in IT would be much better.
The mobile freemium model where
On Monday, 29 September 2014 at 13:01:19 UTC, Bruno Medeiros
wrote:
On 23/09/2014 19:35, H. S. Teoh via Digitalmars-d wrote:
>it game will crash on ANY bug, it will contain alot less
>bugs. 'cause
>even the dumbiest QA full of monkeys will not let the game
>which
>crashes once in a ten second
On 23/09/2014 19:35, H. S. Teoh via Digitalmars-d wrote:
>it game will crash on ANY bug, it will contain alot less bugs. 'cause
>even the dumbiest QA full of monkeys will not let the game which
>crashes once in a ten seconds to go out of the door.
When doing QA, that's a whole different thing
On Tue, Sep 23, 2014 at 09:25:51PM +0300, ketmar via Digitalmars-d wrote:
> On Tue, 23 Sep 2014 15:19:56 +0100
> Bruno Medeiros via Digitalmars-d wrote:
>
> > Even if I had to choose between an occasional savefile corruption
> > that would render a game impossible to win, and having my games
> >
On Tue, 23 Sep 2014 15:19:56 +0100
Bruno Medeiros via Digitalmars-d wrote:
> Even if I had to choose between an occasional savefile corruption
> that would render a game impossible to win, and having my games crash
> every time ANY bug happened, I would still prefer the former.
it game will crash
On 18/09/2014 17:49, H. S. Teoh via Digitalmars-d wrote:
On Thu, Sep 18, 2014 at 05:05:31PM +0100, Bruno Medeiros via Digitalmars-d
wrote:
On 01/08/2014 05:12, Walter Bright wrote:
On 7/31/2014 2:21 PM, Sean Kelly wrote:
Thoughts?
If a process detects a logic error, then that process is in
On Friday, 19 September 2014 at 13:56:14 UTC, Sean Kelly wrote:
I suspect/hope that it won't be long before communications
software is held to standards similar to telephone, which will
require a huge adjustment on the part of programmers. People
in this industry still tend to not think of thi
On Thursday, 18 September 2014 at 16:55:33 UTC, H. S. Teoh via
Digitalmars-d wrote:
Seriously, this philosophy of ignoring supposedly "minor" bugs
in
software is what led to the sad state of software today, where
nothing
is reliable and people have come to expect that software will
inevitably
On Thursday, 18 September 2014 at 16:05:32 UTC, Bruno Medeiros
wrote:
"If it's a game, who cares" -> Oh let's see... let's say I'm
playing a game, and then there's a bug (which happens often).
What would I prefer to happen:
* a small (or big) visual glitch, like pixels out of place,
corrupt
On Thursday, 18 September 2014 at 16:55:33 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Sep 18, 2014 at 07:13:48PM +0300, ketmar via
Digitalmars-d wrote:
On Thu, 18 Sep 2014 17:05:31 +0100
Bruno Medeiros via Digitalmars-d
wrote:
> * a small (or big) visual glitch, like pixels out of plac
On 18/09/14 18:49, H. S. Teoh via Digitalmars-d wrote:
What if the program has a bug that corrupts your save game file, but
because the program ignores these logic errors, it just bumbles onward
and destroys all your progress *without* you even knowing about it until
much later?
Happened to me
The point is that using these enforce() statements means that
these methods cannot be nothrow, which doesn't seem
particularly nice if it can be avoided. Now, on the one hand,
one could say that, quite obviously, these methods cannot
control their input. But on the other hand, it's
On Thu, Sep 18, 2014 at 07:13:48PM +0300, ketmar via Digitalmars-d wrote:
> On Thu, 18 Sep 2014 17:05:31 +0100
> Bruno Medeiros via Digitalmars-d wrote:
>
> > * a small (or big) visual glitch, like pixels out of place,
> > corrupted textures, or 3D model of an object becoming deformed, or
> > the
On Thu, Sep 18, 2014 at 05:05:31PM +0100, Bruno Medeiros via Digitalmars-d
wrote:
> On 01/08/2014 05:12, Walter Bright wrote:
> >On 7/31/2014 2:21 PM, Sean Kelly wrote:
> >>Thoughts?
> >
> >If a process detects a logic error, then that process is in an
> >invalid state that is unanticipated and un
On Thu, 18 Sep 2014 17:05:31 +0100
Bruno Medeiros via Digitalmars-d wrote:
> * a small (or big) visual glitch, like pixels out of place, corrupted
> textures, or 3D model of an object becoming deformed, or the physics
> of some object behaving erratically, or some broken animation.
or the whole
On 01/08/2014 05:12, Walter Bright wrote:
On 7/31/2014 2:21 PM, Sean Kelly wrote:
Thoughts?
If a process detects a logic error, then that process is in an invalid
state that is unanticipated and unknown to the developer. The only
correct solution is to halt that process, and all processes that
On Thu, 18 Sep 2014 08:57:20 -0400, Kagamin wrote:
On Tuesday, 16 September 2014 at 00:33:47 UTC, Steven Schveighoffer
wrote:
The cost for this is tremendous. You may as well not use classes.
Looks like ldc has a separate option to turn off invariants.
That's a good thing. I'm actually th
On Tuesday, 16 September 2014 at 00:33:47 UTC, Steven
Schveighoffer wrote:
The cost for this is tremendous. You may as well not use
classes.
Looks like ldc has a separate option to turn off invariants.
On Tuesday, 16 September 2014 at 00:33:47 UTC, Steven
Schveighoffer wrote:
You may as well not use classes.
Always a good idea ;)
On Fri, 01 Aug 2014 01:07:55 -0400, Jonathan M Davis
wrote:
On Thursday, 31 July 2014 at 20:49:18 UTC, Timon Gehr wrote:
On 07/31/2014 09:37 PM, Jonathan M Davis wrote:
disable contracts, turn assert(0) into a halt
instruction, and disable bounds checking in @system and @trusted code.
So, i
On Tuesday, 5 August 2014 at 16:35:42 UTC, Andrew Godfrey wrote:
out, but in general if the compiler keeps track of properties
of things then it could start making algorithmic-level
performance decisions that today we always have to make by
hand. To me that's interesting.
I think the most "po
On Tuesday, 5 August 2014 at 09:42:26 UTC, Ola Fosheim Grøstad
wrote:
But I don't think this path is all that new… so I hope Walter,
if he continues walking down this path, remains unrelenting and
keeps walking past "assert as assume" until he finds truly new
territory in the realm of formal me
On Monday, 4 August 2014 at 00:59:10 UTC, Andrei Alexandrescu
wrote:
I can totally relate to people who hold a conviction strong
enough to
have difficulty acknowledging a contrary belief as even remotely
reasonable
Yes, it's difficult to acknowledge a belief, reason for which
wasn't provided,
On Tuesday, 5 August 2014 at 10:00:55 UTC, eles wrote:
It is wise to mix them to such degree as to no longer
distinguish them? For me, assume and the like shall rather go
with the annotations.
That's one of the reasons I think it is not new territory, since
letting assert have side effects ba
On Tuesday, 5 August 2014 at 09:42:26 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 4 August 2014 at 00:59:10 UTC, Andrei Alexandrescu
wrote:
For my money, consider Walter's response:
I feel a bit confused about the mixture between compiler and
optimizer. While I agree the compiler does the opti
On Monday, 4 August 2014 at 00:59:10 UTC, Andrei Alexandrescu
wrote:
For my money, consider Walter's response:
What I see is Microsoft attempting to bring D's assert
semantics into
C++. :)
As I've mentioned before, there is inexorable pressure for
this to
happen, and it will happen.
I fin
On Monday, 4 August 2014 at 00:59:10 UTC, Andrei Alexandrescu
wrote:
I find it to the point, clear, and funny. Expanded it would go
like "I see more similarities than differences, and a definite
convergence dictated by market pressure."
I find this to be a non-sequitur. Firstly, making a joke
On Monday, 4 August 2014 at 00:59:10 UTC, Andrei Alexandrescu
wrote:
On 8/3/14, 11:55 AM, Kagamin wrote:
On Saturday, 2 August 2014 at 17:36:46 UTC, David Bregman
wrote:
OK, I'm done. It's clear now that you're just being
intellectually
dishonest in order to "win" what amounts to a trivial
arg
On 8/3/14, 11:55 AM, Kagamin wrote:
On Saturday, 2 August 2014 at 17:36:46 UTC, David Bregman wrote:
OK, I'm done. It's clear now that you're just being intellectually
dishonest in order to "win" what amounts to a trivial argument. So
much for professionalism.
Haha, this time it's not as bad
On Saturday, 2 August 2014 at 17:36:46 UTC, David Bregman wrote:
OK, I'm done. It's clear now that you're just being
intellectually dishonest in order to "win" what amounts to a
trivial argument. So much for professionalism.
Haha, this time it's not as bad as it was in catch syntax
discussion
On Friday, 1 August 2014 at 16:04:21 UTC, Daniel Murphy wrote:
"Johannes Pfau" wrote in message
news:lrgar7$1vrr$1...@digitalmars.com...
Do you know if linkers actually guarantee that behaviour?
AFAICS dmd
doesn't do anything special, it always emits weak symbols and
just calls
gcc to link.
On Sunday, 3 August 2014 at 02:27:16 UTC, Jonathan M Davis wrote:
On Saturday, 2 August 2014 at 09:46:57 UTC, Marc Schütz wrote:
On Friday, 1 August 2014 at 21:50:59 UTC, Jonathan M Davis
wrote:
And why is that a problem? By definition, if an assertion
fails, your code is in an invalid state,
On Saturday, 2 August 2014 at 09:46:57 UTC, Marc Schütz wrote:
On Friday, 1 August 2014 at 21:50:59 UTC, Jonathan M Davis
wrote:
And why is that a problem? By definition, if an assertion
fails, your code is in an invalid state,
Only in an ideal world. In practice, the condition in the
asserti
Am Sat, 02 Aug 2014 12:34:54 -0700
schrieb Walter Bright :
> On 8/1/2014 3:58 PM, Jonathan M Davis wrote:
> > But even if I
> > could think of a better name, I think that we're stuck with -debug
> > at this point.
>
> One thing that people hate even more than breaking existing code is
> breaking
On 8/1/2014 3:58 PM, Jonathan M Davis wrote:
But even if I
could think of a better name, I think that we're stuck with -debug at this
point.
One thing that people hate even more than breaking existing code is breaking
their makefile (or equivalent).
Makefiles typically are cut&pasted from s
On 8/1/2014 4:24 PM, bearophile wrote:
H. S. Teoh:
IMO the correct solution is for the compiler to insert preconditions at the
calling site,
I have seen this suggestion tens of times, but nothing has happened. (delegates
make the management of contract blame more compex).
There's a bugzilla
On Saturday, 2 August 2014 at 05:35:26 UTC, Walter Bright wrote:
On 8/1/2014 7:13 PM, David Bregman wrote:
OK, I think I have an idea how to be more convincing (I wish
I'd thought of this
earlier):
is this
http://www.cplusplus.com/reference/cassert/assert/
the same as this?
http://msdn.micros
"bearophile" wrote in message news:nadqefjfnjfzghope...@forum.dlang.org...
What defines "possible"? A compiler switch that allows to define the
amount of compile time?
At the moment it's the criteria I listed in the bug report. Beyond this, it
will be limited by what constfolding is capable
By the way, I will be absent for more than a week. My comments or
answers in bug reports and threads will have to wait.
Bye,
bearophile
Daniel Murphy:
This doesn't need a lot of text to explain either: "when
possible, the compiler will check preconditions at compile time"
What defines "possible"? A compiler switch that allows to define
the amount of compile time?
I feel like you're confusing this pull request with another
"bearophile" wrote in message news:hnbybyssdlwaomesc...@forum.dlang.org...
I like compile-time tests, you can see it from several of my last posts,
but:
1) It's better to be able to express general tests using CTFE, instead of
covering a limited but growing list of cases. The general solution
On Saturday, 2 August 2014 at 06:01:30 UTC, Walter Bright wrote:
As to the substance of your question, I can't do it proper
justice in a few lines. It's an important issue, and it is
worthwhile to thoroughly understand it, especially for the kind
of programming you do and the leading role you h
On Friday, 1 August 2014 at 21:50:59 UTC, Jonathan M Davis wrote:
On Friday, 1 August 2014 at 20:30:19 UTC, Daniel Gibson wrote:
Am 01.08.2014 22:16, schrieb eles:
On Friday, 1 August 2014 at 17:43:27 UTC, Timon Gehr wrote:
On 08/01/2014 07:19 PM, Sebastiaan Koppe wrote:
The debug and the re
On Saturday, 2 August 2014 at 06:44:48 UTC, Walter Bright wrote:
On 8/1/2014 11:08 PM, Timon Gehr wrote:
You evaded the question.
Those have been posted here before, and I responded in detail
to them, more than once.
I have nothing new to say about it.
Honestly, how can you be so comforta
Daniel Murphy:
What do you think about
https://github.com/D-Programming-Language/dmd/pull/3799 ?
Basically, turn obviously invalid failing function calls into
compile-time errors. IMO this pushes in-contracts well out of
the useless area.
I like compile-time tests, you can see it from sev
"Jonathan M Davis" wrote in message
news:zbkvnbibbmcfwhjvm...@forum.dlang.org...
> IMO the correct solution is for the compiler to insert preconditions at
> the calling site, rather than the callee.
If we had that, I'd actually start using in blocks. As it is, I think that
they're useless e
On 8/1/2014 11:08 PM, Timon Gehr wrote:
You evaded the question.
Those have been posted here before, and I responded in detail to them, more than
once.
I have nothing new to say about it.
On 08/02/2014 07:35 AM, Walter Bright wrote:
On 8/1/2014 7:13 PM, David Bregman wrote:
OK, I think I have an idea how to be more convincing (I wish I'd
thought of this
earlier):
is this
http://www.cplusplus.com/reference/cassert/assert/
the same as this?
http://msdn.microsoft.com/en-us/library
On 08/02/2014 08:04 AM, eles wrote:
On Saturday, 2 August 2014 at 06:01:52 UTC, Timon Gehr wrote:
On 08/02/2014 07:56 AM, eles wrote:
On Friday, 1 August 2014 at 20:22:39 UTC, Tofu Ninja wrote:
On Friday, 1 August 2014 at 20:16:29 UTC, eles wrote:
It's part of the language standard. The com
On 08/02/2014 07:56 AM, eles wrote:
On Friday, 1 August 2014 at 20:22:39 UTC, Tofu Ninja wrote:
On Friday, 1 August 2014 at 20:16:29 UTC, eles wrote:
Yes, but is the same for the C apps. There, you have no assertion in
the release build, the release build is optimized (I imagine very few
would
On 8/1/2014 5:57 PM, Dicebot wrote:
`enforce` does have overload which allows to use pre-allocated exception
instance. Or, alternatively, we may need a similar helper wich does `if
(!condition) abort()` with no interaction with -release or optimizer.
It still throws a *recoverable* exception
On Saturday, 2 August 2014 at 06:01:52 UTC, Timon Gehr wrote:
On 08/02/2014 07:56 AM, eles wrote:
On Friday, 1 August 2014 at 20:22:39 UTC, Tofu Ninja wrote:
On Friday, 1 August 2014 at 20:16:29 UTC, eles wrote:
It's part of the language standard. The compiler can make as
much use of it as p
On Friday, 1 August 2014 at 20:22:39 UTC, Tofu Ninja wrote:
On Friday, 1 August 2014 at 20:16:29 UTC, eles wrote:
Yes, but is the same for the C apps. There, you have no
assertion in the release build, the release build is optimized
(I imagine very few would use -O0 on it...), then the sefault
On 8/1/2014 7:13 PM, David Bregman wrote:
OK, I think I have an idea how to be more convincing (I wish I'd thought of this
earlier):
is this
http://www.cplusplus.com/reference/cassert/assert/
the same as this?
http://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx
can you see the difference now
Am 02.08.2014 04:13, schrieb David Bregman:
is this
http://www.cplusplus.com/reference/cassert/assert/
the same as this?
http://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx
can you see the difference now?
Oh, interesting quote from the __assume() link:
"Use __assume in an ASSERT only when
On Saturday, 2 August 2014 at 00:18:30 UTC, Walter Bright wrote:
On 8/1/2014 4:03 PM, David Bregman wrote:
Unfortunately these "detailed rationales" consisted mostly of
attacking straw
men, and some other unsound arguments :(
Of course, we always believe the other side's arguments are of
that
application code,
use `enforce`
instead
2) never use `enforce` in library code unless it does actual
I/O, use contracts
instead
3) always distribute both release and debug builds of
libraries and always run
tests in both debug and release mode
Does it make sense? Your actual recommendation
On 08/02/2014 02:04 AM, H. S. Teoh via Digitalmars-d wrote:
On Sat, Aug 02, 2014 at 01:59:29AM +0200, Timon Gehr via Digitalmars-d wrote:
On 08/02/2014 01:46 AM, H. S. Teoh via Digitalmars-d wrote:
OTOH, perhaps one way to work around this, is to have a function with
an in-contract compile into
On 08/02/2014 02:18 AM, Walter Bright wrote:
On 8/1/2014 4:03 PM, David Bregman wrote:
Unfortunately these "detailed rationales" consisted mostly of
attacking straw
men, and some other unsound arguments :(
Of course, we always believe the other side's arguments are of that
nature when we find
On 8/1/2014 4:03 PM, David Bregman wrote:
Unfortunately these "detailed rationales" consisted mostly of attacking straw
men, and some other unsound arguments :(
Of course, we always believe the other side's arguments are of that nature when
we find them unconvincing.
To quote my favorite Ham
On Sat, Aug 02, 2014 at 02:04:22AM +0200, Timon Gehr via Digitalmars-d wrote:
> On 08/02/2014 01:52 AM, H. S. Teoh via Digitalmars-d wrote:
> >On Sat, Aug 02, 2014 at 01:47:42AM +0200, Timon Gehr via Digitalmars-d wrote:
> >>On 08/02/2014 01:03 AM, H. S. Teoh via Digitalmars-d wrote:
> >>>Actually,
On Sat, Aug 02, 2014 at 01:59:29AM +0200, Timon Gehr via Digitalmars-d wrote:
> On 08/02/2014 01:46 AM, H. S. Teoh via Digitalmars-d wrote:
> >OTOH, perhaps one way to work around this, is to have a function with
> >an in-contract compile into a preamble and a body:
> >
> > int func(int x)
> >
On 08/02/2014 01:52 AM, H. S. Teoh via Digitalmars-d wrote:
On Sat, Aug 02, 2014 at 01:47:42AM +0200, Timon Gehr via Digitalmars-d wrote:
On 08/02/2014 01:03 AM, H. S. Teoh via Digitalmars-d wrote:
Actually, I'm thinking of ways of extending this even further, ...
Note that the official stanc
On 08/02/2014 01:46 AM, H. S. Teoh via Digitalmars-d wrote:
OTOH, perhaps one way to work around this, is to have a function with an
in-contract compile into a preamble and a body:
int func(int x)
in { assert(x > 5); }
body {
return computeResult(x);
On 08/02/2014 01:51 AM, H. S. Teoh via Digitalmars-d wrote:
On Sat, Aug 02, 2014 at 01:46:44AM +0200, Timon Gehr via Digitalmars-d wrote:
On 08/02/2014 12:58 AM, Jonathan M Davis wrote:
something like --remove-assertions.
What would that do?
Automatically edit your source files and delete a
On Sat, Aug 02, 2014 at 01:47:42AM +0200, Timon Gehr via Digitalmars-d wrote:
> On 08/02/2014 01:03 AM, H. S. Teoh via Digitalmars-d wrote:
> >Actually, I'm thinking of ways of extending this even further, ...
>
> Note that the official stance has been that such things are obviously
> ridiculous i
On Sat, Aug 02, 2014 at 01:46:44AM +0200, Timon Gehr via Digitalmars-d wrote:
> On 08/02/2014 12:58 AM, Jonathan M Davis wrote:
> >something like --remove-assertions.
>
> What would that do?
Automatically edit your source files and delete all assert expressions
for you.
:-D
T
--
Why waste ti
On 08/02/2014 01:03 AM, H. S. Teoh via Digitalmars-d wrote:
Actually, I'm thinking of ways of extending this even further, ...
Note that the official stance has been that such things are obviously
ridiculous if not checked dynamically in non-release mode.
On 08/02/2014 12:58 AM, Jonathan M Davis wrote:
something like --remove-assertions.
What would that do?
On Fri, Aug 01, 2014 at 11:24:29PM +, bearophile via Digitalmars-d wrote:
> H. S. Teoh:
>
> >IMO the correct solution is for the compiler to insert preconditions
> >at the calling site,
>
> I have seen this suggestion tens of times, but nothing has happened.
> (delegates make the management o
On 8/1/2014 4:12 PM, Jonathan M Davis wrote:
True, but as long as the runtime cost isn't too great for your debug builds,
having assertions for whatever conditions you think your code relies on and
would ideally be checked is quite beneficial. Any optimizations by the compiler
would then be a bon
On 08/02/2014 01:19 AM, Jonathan M Davis wrote:
If we had that, I'd actually start using in blocks. As it is, I think
that they're useless except when inheritance is involved,
And when it is involved, they are broken because the compiler insists on
removing them on each override by default.
H. S. Teoh:
IMO the correct solution is for the compiler to insert
preconditions at the calling site,
I have seen this suggestion tens of times, but nothing has
happened. (delegates make the management of contract blame more
compex).
Bye,
bearophile
On Friday, 1 August 2014 at 23:13:28 UTC, H. S. Teoh via
Digitalmars-d wrote:
IMO the correct solution is for the compiler to insert
preconditions at the calling site, rather than the callee.
If we had that, I'd actually start using in blocks. As it is, I
think that they're useless except wh
On Friday, 1 August 2014 at 22:34:02 UTC, Walter Bright wrote:
On 8/1/2014 2:50 PM, Jonathan M Davis wrote:
Thinking about it, I'm actually wondering if I should use
assertions _more_ so
that the compiler might be able to do better optimizations in
-release.
I think this will be a productive
On Fri, Aug 01, 2014 at 10:34:20PM +, Sean Kelly via Digitalmars-d wrote:
> On Friday, 1 August 2014 at 16:52:00 UTC, Daniel Murphy wrote:
> >"Sean Kelly" wrote in message
> >news:tngnltzwxprebpbcd...@forum.dlang.org...
> >
> >>Druntime uses contracts and asserts in places. Which are of course
On Fri, Aug 01, 2014 at 03:34:00PM -0700, Walter Bright via Digitalmars-d wrote:
> On 8/1/2014 2:50 PM, Jonathan M Davis wrote:
> >Thinking about it, I'm actually wondering if I should use assertions
> >_more_ so that the compiler might be able to do better optimizations
> >in -release.
>
> I thin
On Friday, 1 August 2014 at 20:57:29 UTC, Walter Bright wrote:
On 8/1/2014 12:47 PM, Tofu Ninja wrote:
Having your augment consistently dismissed by "I see no
difference" or "That is
misuse" is frustrating to say the least.
Indeed.
I repeatedly gave detailed rationales for that.
Unfortuna
(which are compiled in release mode)? BTW,
druntime can't use enforce and doesn't verify its input.
Druntime uses contracts and asserts in places. Which are of
course removed because we ship only a "release" build. Once
again, the worst naming for a compiler switch ever. What I
On Friday, 1 August 2014 at 21:51:10 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Fri, Aug 01, 2014 at 09:42:06PM +, Jonathan M Davis via
Digitalmars-d wrote:
On Friday, 1 August 2014 at 14:10:14 UTC, Sean Kelly wrote:
[...]
But we probably would be better off if none of the switches
had na
On 8/1/2014 3:34 PM, Sean Kelly wrote:
Also, I don't like the -debuglib option because when a user sets
the debug flag in their build, what they want is to debug their
own code, not the standard library. While it's sometimes useful
to have debug symbols in the standard library you're linking
aga
On 8/1/2014 7:33 AM, Kagamin wrote:
Nobody cares about intermediate files,
I do because it influences build speed, which is a major feature of D.
On Friday, 1 August 2014 at 16:52:00 UTC, Daniel Murphy wrote:
"Sean Kelly" wrote in message
news:tngnltzwxprebpbcd...@forum.dlang.org...
Druntime uses contracts and asserts in places. Which are of
course removed because we ship only a "release" build. Once
again, the worst naming for a com
On 8/1/2014 2:50 PM, Jonathan M Davis wrote:
Thinking about it, I'm actually wondering if I should use assertions _more_ so
that the compiler might be able to do better optimizations in -release.
I think this will be a productive strategy once this gets implemented in
optimizers.
Of course, u
On 08/01/2014 11:50 PM, Jonathan M Davis wrote:
... as far as correctness goes, it never hurts to have more assertions.
Pipe dream.
On Friday, 1 August 2014 at 20:30:19 UTC, Daniel Gibson wrote:
Am 01.08.2014 22:16, schrieb eles:
On Friday, 1 August 2014 at 17:43:27 UTC, Timon Gehr wrote:
On 08/01/2014 07:19 PM, Sebastiaan Koppe wrote:
The debug and the release build may be subjected to different
input
and hence traverse
On Fri, Aug 01, 2014 at 09:42:06PM +, Jonathan M Davis via Digitalmars-d
wrote:
> On Friday, 1 August 2014 at 14:10:14 UTC, Sean Kelly wrote:
[...]
> But we probably would be better off if none of the switches had names
> like -release or -debug so that folks actually had to figure out what
>
parameters
using
assert() because the user of that library knows what the
library
expects and should write their code accordingly. That's fair.
He should, but what if he doesn't and the library is phobos or
druntime (which are compiled in release mode)? BTW, druntime
can't use enfo
On 8/1/14, 5:16 PM, eles wrote:
On Friday, 1 August 2014 at 17:43:27 UTC, Timon Gehr wrote:
On 08/01/2014 07:19 PM, Sebastiaan Koppe wrote:
The debug and the release build may be subjected to different input
and hence traverse different traces of abstract states. It is not
valid to say that a
On 8/1/2014 12:47 PM, Tofu Ninja wrote:
Having your augment consistently dismissed by "I see no difference" or "That is
misuse" is frustrating to say the least.
I repeatedly gave detailed rationales for that.
1 - 100 of 626 matches
Mail list logo
