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 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
On 08/02/2014 03:11 AM, Chris Cain wrote:
However, by not stating what it is you have provided "strong evidence" for,
Why would I need to? It is what you were arguing against: "You will
notice it uses the word 'assertion' in a way that is incompatible with
your claim that the "assert definiti
On 08/02/2014 03:19 AM, Andrei Alexandrescu wrote:
Clearly avoiding those clashes was all business as usual,
The newly introduced _private_ aliases would have possibly led to more
clashes, aggravating the issue.
On 08/02/2014 04:28 AM, Chris Cain wrote:
...
I retract my apology.
On 08/02/2014 04:41 AM, Chris Cain wrote:
Here, I'll do you the favor of giving you a few more Google results with hopes
that you'll
start developing a mental model behind what the definition of assertion is:
...
Great, that's a lot more useful than the personal attacks. Thanks!
Google itsel
On 08/02/2014 04:42 AM, Chris Cain wrote:
On Saturday, 2 August 2014 at 02:32:45 UTC, Timon Gehr wrote:
On 08/02/2014 04:28 AM, Chris Cain wrote:
...
I retract my apology.
Of course. The worst curse I could wish upon you is that you stick to
your guns. So stick to your guns, my friend. :-)
On 08/02/2014 05:14 AM, Chris Cain wrote:
On Saturday, 2 August 2014 at 03:07:25 UTC, Tofu Ninja wrote:
D3 anyone? :)
Macros please. God please. I assert(macrosExist);
core.exception.AssertError@chris(332812126): Assertion failure
chris(_d_assertm+0x26) [0x41601a]
chris() [0
On 08/02/2014 05:40 AM, Timon Gehr wrote:
Do you see why I think that the definition of 'assertion' in English is
not sufficient to describe it's
Argh, it's getting late.
On 08/02/2014 06:05 AM, Chris Cain wrote:
On Saturday, 2 August 2014 at 04:00:01 UTC, Timon Gehr wrote:
On 08/02/2014 05:14 AM, Chris Cain wrote:
On Saturday, 2 August 2014 at 03:07:25 UTC, Tofu Ninja wrote:
D3 anyone? :)
Macros please. God please. I assert(macrosExist);
core.exception.Ass
On 08/02/2014 06:11 AM, Chris Cain wrote:
On Saturday, 2 August 2014 at 03:40:47 UTC, Timon Gehr wrote:
I already googled 'statement of fact' myself earlier, and found the
wikipedia entry for 'fact', that I quoted back then:
http://en.wikipedia.org/wiki/Fact
"The usual test for a statement of f
On 08/02/2014 06:28 AM, Timon Gehr wrote:
On 08/02/2014 06:11 AM, Chris Cain wrote:
...
So no, a statement of fact can be verifiable and still false by your
quote.
It is possible that this is indeed what it tries to communicate. Thanks
for bearing with me in any case!
But as I wrote in my
On 08/02/2014 06:40 AM, Tofu Ninja wrote:
Ok that was my interpretation of both of your interpretations. I
hope I didn't misinterpret.
Your interpretation of my interpretation is exactly right. (However,
note that I am not using this reasoning to say the new semantics are
wrong, I am saying
On 08/02/2014 06:46 AM, Chris Cain wrote:
On Saturday, 2 August 2014 at 04:28:33 UTC, Timon Gehr wrote:
On 08/02/2014 06:11 AM, Chris Cain wrote:
On Saturday, 2 August 2014 at 03:40:47 UTC, Timon Gehr wrote:
I already googled 'statement of fact' myself earlier, and found the
wikipedia entry fo
On 08/02/2014 06:54 AM, Andrei Alexandrescu wrote:
I don't think there's ever been a more majestic thread in the history of
this forum. Probably up there with the best of them anywhere and
anytime. It's become officially an Epic Debate.
Andrei
Wait, does this thread outclass the @property deb
On 08/02/2014 05:34 AM, Andrew Godfrey wrote:
Suppose I call some logging function which has a faulty assertion in it.
What about Walter's position prevents that assertion's effects from
escaping the logging function and infecting my code?
Nothing. Undefined behaviour is completely non-modular.
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 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 08:40 AM, Andrew Godfrey wrote:
So even if the assertion is incorrect and the code is correct, the
caller's correctness can be compromised?
Yes. The reasoning is that if the assertion is incorrect, the program is
fundamentally broken, it enters an invalid state and hence it is f
On 08/02/2014 08:09 AM, Chris Cain wrote:
On Saturday, 2 August 2014 at 05:32:43 UTC, Timon Gehr wrote:
Well, if there is no proof of something, how can I claim it can be
proven? In fact, in my past life, when somebody told me something like
'...and actually one _can prove_ that any non-planar g
On 08/02/2014 09:00 AM, Chris Cain wrote:
On Saturday, 2 August 2014 at 06:36:00 UTC, Timon Gehr wrote:
http://en.wikipedia.org/wiki/Falsifiability
^^ See?
"A statement is called falsifiable if it is possible to conceive an
observation or an argument which proves the statement in question to
On 08/02/2014 05:08 PM, Andrei Alexandrescu wrote:
On 8/2/14, 5:44 AM, Artur Skawina via Digitalmars-d wrote:
auto fx(ubyte* p, size_t len) @safe {
assert_(len>0);
if (len>=1)
return p[0];
return -1;
}
As an aside I think it's a bug that this function pass
On 08/02/2014 06:03 PM, Paolo Invernizzi wrote:
On Friday, 1 August 2014 at 18:33:34 UTC, Walter Bright wrote:
On 8/1/2014 4:53 AM, Don wrote:
I think very strongly that we should rename the "-release" switch,
especially if
we do start to make use of asserts. It's going to cause no end of
confu
On 08/02/2014 09:01 PM, Walter Bright wrote:
I think at this point it is quite clear that D's assert is about the
programmer saying this expression evaluates to true or it's a
programming bug.
That was already obvious to most before the discussion started.
In any case, the way you'd need to p
On 08/02/2014 11:36 PM, Tobias Pankrath wrote:
On Saturday, 2 August 2014 at 21:25:40 UTC, Ola Fosheim Grøstad wrote:
On Saturday, 2 August 2014 at 20:27:09 UTC, Andrei Alexandrescu wrote:
Hmmm... code that fails assertions is hardly working. -- Andrei
It is not the code that fails the assert
On 08/03/2014 11:15 AM, Paolo Invernizzi wrote:
because every few milliseconds an assert is triggered
Right, and software does not have security holes because otherwise they
would obviously be exploited every few milliseconds during in-house testing.
the colleague reading the sources is exp
On 08/03/2014 03:01 PM, Paolo Invernizzi wrote:
On Sunday, 3 August 2014 at 10:49:39 UTC, Timon Gehr wrote:
On 08/03/2014 11:15 AM, Paolo Invernizzi wrote:
because every few milliseconds an assert is triggered
Right, and software does not have security holes because otherwise
they would obvio
On 08/03/2014 05:00 PM, Paolo Invernizzi wrote:
On Sunday, 3 August 2014 at 14:10:29 UTC, Timon Gehr wrote:
On 08/03/2014 03:01 PM, Paolo Invernizzi wrote:
On Sunday, 3 August 2014 at 10:49:39 UTC, Timon Gehr wrote:
On 08/03/2014 11:15 AM, Paolo Invernizzi wrote:
because every few millisecond
On 08/03/2014 11:03 PM, Paolo Invernizzi wrote:
...
But most yes: to me, an undefined behaviour is the situation where I've
developed the code for having 'a' in one place, and I have 'b'. If this
is not, literally undefined behaviour, I donno how I should name it.
...
You could name it a bug,
On 08/04/2014 12:15 AM, Andrei Alexandrescu wrote:
I suspect it is one of those ideas of Walter's that has consequences
that reach further than anyone foresees. but that's OK, because it
is fundamentally the correct course of action, it's implications
foreseen and unforeseen will be correct.
On 08/04/2014 12:51 AM, John Carter wrote:
On Sunday, 3 August 2014 at 22:19:16 UTC, Ola Fosheim Grøstad wrote:
But go ahead. This will lead to a fork.
What should fork is the two opposing intentions for assert.
They should have two different names and different consequences.
Yes. :)
On 08/05/2014 08:18 PM, Jeremy Powers via Digitalmars-d wrote:
And there will be no injection of undefined behaviour - the undefined
behaviour is already there if the asserted constraints are not valid.
Well, no. http://en.wikipedia.org/wiki/Undefined_behavior
On 08/05/2014 08:59 PM, Jeremy Powers via Digitalmars-d wrote:
...
Well, yes: Undefined behaviour in the sense
"And there will be no injection of undefined behaviour
^~~
conventional sense
- the undefined b
On 08/06/2014 11:18 PM, Matthias Bentrup wrote:
Ah, I had a different understanding of assume, i.e. placing an
assume(A) at some point in code adds not the axiom A, but rather
the axiom "control flow reaches this spot => A".
(Your understanding is the conventional one.)
On 08/09/2014 07:11 PM, H. S. Teoh via Digitalmars-d wrote:
This causes a segfault at runtime. Moving the declaration of r inside
main() fixes the problem. Why?
My guess is it is just a missing diagnostic for the missing support for
closures in CTFE.
You are effectively trying to do somethi
On 08/09/2014 09:26 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
On Thursday, 7 August 2014 at 23:13:15 UTC, David Bregman wrote:
and use unreachable() if you know 100% it holds.
This is just another name for the same thing, it isn't any more or
less dangerous.
Of course it is. unreach
On 08/10/2014 04:40 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
On Saturday, 9 August 2014 at 20:22:36 UTC, Timon Gehr wrote:
Formally, that's what it assumes to be the case. If you can prove
'false', this means that the code is unreachable.
No, if you prove false that means either that
On 08/10/2014 08:34 PM, Era Scarecrow wrote:
Although I'm not sure how much it adds for complexity to the compiler
(if any).
It is a trivial change in the parser.
On 08/11/2014 01:26 AM, Era Scarecrow wrote:
While we're on the topic of slides and it's slightly related, Walter
Bright brought up an example of code that showed poor optimization that
the compiler should be doing. Like using bit shifts to do
multiply/divide by a power of 2.
i/8 vs i>>3
On 08/14/2014 07:39 PM, Ali Çehreli wrote:
On 08/11/2014 08:40 AM, Jonathan Marler wrote:
> I know this is kinda "nit picky" but it would be nice if foreach
> supported iterating through input ranges without accessing the front
> function.
>
> foreach(myInputRange) {
> // myInputRange
On 08/14/2014 08:26 PM, bearophile wrote:
Andrei Alexandrescu:
Destroy https://issues.dlang.org/show_bug.cgi?id=13291?
I'd like a way to test nested functions:
void foo() {
int bar() { return 0; }
unittest {
assert(bar() == 1);
}
}
void main() {}
Bye,
bearophile
On 08/14/2014 08:39 PM, Timon Gehr wrote:
On 08/14/2014 08:26 PM, bearophile wrote:
Andrei Alexandrescu:
Destroy https://issues.dlang.org/show_bug.cgi?id=13291?
I'd like a way to test nested functions:
...
void foo() {
int bar() { return 0; }
unittest {
assert(bar() == 1);
On 08/15/2014 07:18 PM, John wrote:
btw, it works either way if I use auto
auto const minWage = 11; //works
const auto minWage = 11; //works
...
auto does not serve any purpose here.
The same flexibility is missing when the actual type is used.
In particular, auto is not a wild-card type
On 08/16/2014 12:21 AM, ketmar via Digitalmars-d wrote:
so we can see that things like 'case n+=5:' should be allowed, while
they are not.
What is the problem? This passes DMD's parser.
On 08/16/2014 01:41 AM, ketmar via Digitalmars-d wrote:
On Sat, 16 Aug 2014 01:31:42 +0200
Timon Gehr via Digitalmars-d wrote:
What is the problem? This passes DMD's parser.
that is the problem: it shouldn't.
That's not what you said.
On 08/16/2014 12:21 AM, ketmar via Digi
On 08/19/2014 07:11 PM, bachmeier wrote:
On Tuesday, 19 August 2014 at 16:17:02 UTC, Dicebot wrote:
On Tuesday, 19 August 2014 at 15:16:31 UTC, Ary Borenszweig wrote:
Also, the list seems way too big. It's ok from a purist point of
view, to make the compiler nice and clean. But that's not a goo
On 08/19/2014 09:07 PM, Philippe Sigaud via Digitalmars-d wrote:
I remember finding this while exploring Haskell, some years ago:
http://www.haskell.org/haskellwiki/Zygohistomorphic_prepromorphisms
And thinking: Ah, I get it, it's a joke: they know they are considered
a bunch of strangely mathe
On 08/20/2014 05:24 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
" wrote:
On Wednesday, 20 August 2014 at 15:08:52 UTC, Peter Alexander wrote:
On Wednesday, 20 August 2014 at 14:52:59 UTC, ketmar via Digitalmars-d
wrote:
On Wed, 20 Aug 2014 14:44:40 +
Peter Alexander via Digitalmars-d wrote:
Well,
On 08/22/2014 09:07 PM, bearophile wrote:
Apparently there is evidence that unused variables in C-like languages
correlate with bugs:
https://kev.inburke.com/slides/errors/#error-correlations
...
http://xkcd.com/552/
On 08/23/2014 01:32 AM, Timon Gehr wrote:
you seemed to suggest in the OT.
OP
On 08/22/2014 11:46 PM, bearophile wrote:
Timon Gehr:
http://xkcd.com/552/
...
My point is just that this correlation is not a strong data point
supporting putting effort into elimination of unused variables. It is
possible that all this will accomplish is that unused variables will no
lo
On 08/23/2014 02:03 AM, Brian Schott wrote:
On Friday, 22 August 2014 at 23:32:54 UTC, Timon Gehr wrote:
The correlation only indicates that poor code tends to have more
unused variables. If one eliminates unused variables just for the sake
of eliminating unused variables, code quality will most
On 08/25/2014 12:53 PM, Russel Winder via Digitalmars-d wrote:
For example:
a + b
is not a message in Java as it is in C++, ...
error: member reference base type 'int' is not a structure or union
int main(){ (1).operator+(2); }
~~~^
On 08/26/2014 05:46 PM, Uranuz wrote:
In the pre-last paragraph please read text^
Also notice that C is language with weak type system but D is
declared to have type system.
as:
Also notice that C is language with weak type system but D is
declared to have *strong* type system.
It's not _that_
On 08/26/2014 10:13 PM, Cliff wrote:
On Tuesday, 26 August 2014 at 19:47:25 UTC, Casper Færgemand
wrote:
How would this even work?
It looks like this applies only to the inference of immutability
based on the structure of the type and its methods, as opposed to
a declaration of immutability.
On 08/28/2014 11:53 AM, "Jérôme M. Berger" wrote:
...
I should have said that in D it is used when declaring an instance
(i.e. at the place of the instance declaration) whereas in the
patent it is used when declaring the type. For a patent lawyer, this
will be enough to say that the pate
On 08/28/2014 07:34 PM, Walter Bright wrote:
Aliases are not really prior art either since they do not allow
creating an immutable type without also creating the corresponding
mutable type.
This seems to me to be reductio ad absurdum. And how does the patent say
an immutable T is to be cr
On 09/03/2014 11:38 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
[...] I believe √ and π can be done in a heartbeat.
What about π? This is already valid code: auto π=3;
On 09/08/2014 10:51 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
What kind of syntactical sugar do you feel is missing in D?
int square(int x)=>x*x;
On 09/08/2014 07:00 PM, Marco Leise wrote:
Am Mon, 8 Sep 2014 18:34:10 +0300
schrieb ketmar via Digitalmars-d :
On Mon, 08 Sep 2014 17:25:07 +0200
Timon Gehr via Digitalmars-d wrote:
int square(int x)=>x*x;
noted.
To clarify:
The above is not valid D 2.066 syntax.
Your appar
On 09/08/2014 07:02 PM, Andrei Alexandrescu wrote:
However std.algorithm also includes stuff that's arguably numeric, e.g.
min and max etc.
How are min and max numeric?
On 09/08/2014 04:58 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
comics are not on topic,
The topic of a comic is arbitrary.
On 09/10/2014 07:01 AM, Kagamin wrote:
It's questionable that testing every template instantiation is intended:
you can't do the same for templated functions.
Yes you can.
On 09/10/2014 03:22 PM, Daniel Murphy wrote:
"Jacob Carlborg" wrote in message news:lupda8$nl1$1...@digitalmars.com...
Could we modify the compiler to allow that? Just for the special
identifiers __LINE__, __FILE__ and similar. It wouldn't be possible to
specify a value for that parameter then.
On 09/09/2014 07:05 PM, Wyatt wrote:
APL actually has really neat semantics (seriously, every programmer
would do well to at least learn _how APL works_) ...
One can do this quite efficiently e.g. here: http://tryapl.org/
On 09/10/2014 08:18 PM, Sönke Ludwig wrote:
Am 10.09.2014 17:41, schrieb Timon Gehr:
On 09/10/2014 03:22 PM, Daniel Murphy wrote:
"Jacob Carlborg" wrote in message news:lupda8$nl1$1...@digitalmars.com...
Could we modify the compiler to allow that? Just for the special
identifiers __LINE__, __
On 09/10/2014 06:54 PM, Dicebot wrote:
On Wednesday, 10 September 2014 at 16:34:06 UTC, Andrei Alexandrescu wrote:
One possibility is to have the first function be a one-liner that
forwards to another. That way there will be less code bloating.
void fun(uint l = __LINE__, A...)(A... as) {
fun
On 09/11/2014 01:46 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
The D community is as
diverse as the language and even if three people yell in the
same tone, it doesn't mean everyone else believes the same.
I know that, but newbies don't know that. [...]Exchanging mods with other
newbie
On 09/11/2014 06:45 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
On Thursday, 11 September 2014 at 14:14:38 UTC, Timon Gehr wrote:
...
Which unsound general statement? ...
I was quoting relevant passages.
...
If the community
'the community'?
is trying to undermine the license
On 09/13/2014 03:36 AM, Manu via Digitalmars-d wrote:
Surely, at very least, an extern(C++) class should be final-by-default?
How do you declare virtual extern(C++) class methods then?
On 09/13/2014 06:44 PM, Kagamin wrote:
Is there a reason, why you would need inout there?
s.bar((int* p){ ++*p; });
On 09/13/2014 07:54 PM, Kagamin wrote:
From https://issues.dlang.org/show_bug.cgi?id=10850:
Since apparently inout now refers to the outermost inout function
This sounds questionable. Anybody knows, what happened?
It's one of Kenji Hara's occasional stealth language
changes/refinements. It
On 09/13/2014 07:48 PM, Kagamin wrote:
On Saturday, 13 September 2014 at 16:51:09 UTC, Timon Gehr wrote:
s.bar((int* p){ ++*p; });
Huh? inout is for functions, which don't modify their arguments.
With Jakob's code working, this would not be warranted. (But the
situation needs to change in a
On 09/13/2014 09:07 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
" wrote:
Wouldn't `const` be enough? AFAICS, `immutable` is mostly useful for
shared data.
const prevents modification, but does not guarantee that no modification
takes place elsewhere. I.e. it enables fewer program transformations.
On 09/13/2014 09:58 PM, Kagamin wrote:
On Saturday, 13 September 2014 at 18:36:53 UTC, Timon Gehr wrote:
On 09/13/2014 07:48 PM, Kagamin wrote:
On Saturday, 13 September 2014 at 16:51:09 UTC, Timon Gehr wrote:
s.bar((int* p){ ++*p; });
Huh? inout is for functions, which don't modify their ar
On 09/14/2014 01:21 AM, Peter Alexander wrote:
On Saturday, 13 September 2014 at 22:25:57 UTC, Walter Bright wrote:
Yeah, well, we have many years of experience with "static if" and no
apocalypse has yet happened.
Well, we are yet to define "static if" when it comes to tricky cases,
i.e. cases
On 09/13/2014 10:10 PM, eles wrote:
...
But the surprise comes at the end (slide 57), where he also
criticizes... the static if ...
Are those points valid?:
...
• Unstructured, can do everything (just like goto)
• Complicates static analysis (AST-based tools get hard to write)
• Blocks the path
On 09/14/2014 10:47 AM, Kagamin wrote:
On Saturday, 13 September 2014 at 23:41:55 UTC, Timon Gehr wrote:
All the examples there keep their non-modification guarantees.
Modifications to inout parameters are visible at the call site.
Modifications are visible if you know the inout argument will
On 09/14/2014 10:50 AM, Kagamin wrote:
On Sunday, 14 September 2014 at 01:38:33 UTC, Jakob Ovrum wrote:
This is necessary for `inout` to work with callback functions, such as
with internal iteration (i.e. `opApply`).
Can you write a pass and xfail test for it? This scenario looks
non-trivial.
On 09/15/2014 12:38 AM, Walter Bright wrote:
On 9/14/2014 2:48 PM, deadalnix wrote:
If that is really a concern, please consider commenting on
http://wiki.dlang.org/DIP31
I haven't thought it through, but the DIP looks like a good idea.
It should add the test case in this thread,
static i
On 09/14/2014 07:42 PM, Andrei Alexandrescu wrote:
On 9/14/14, 6:17 AM, "Marc Schütz" " wrote:
What if the operation failed without producing an exception? I.e., if we
wrap an API that signals errors by returning false for example, do we
really need to create an exception just to store it in `r.
On 09/15/2014 04:53 AM, Timon Gehr wrote:
On 09/15/2014 12:38 AM, Walter Bright wrote:
On 9/14/2014 2:48 PM, deadalnix wrote:
If that is really a concern, please consider commenting on
http://wiki.dlang.org/DIP31
I haven't thought it through, but the DIP looks like a good idea.
It should add
On 09/17/2014 03:43 AM, Orvid King wrote:
Why all this talk?
I've created pull request for dmd, which allows UDA for modules
(https://github.com/D-Programming-Language/dmd/pull/3947) and Walter
says that I should open topic in n.g. and justify the usefulness of this
enhancement.
As far as I a
On 09/19/2014 12:06 AM, Brian Schott wrote:
On Thursday, 18 September 2014 at 21:31:26 UTC, Peter Alexander wrote:
Maybe in this case
And in every case. DMD's behavior is correct because it consistent with
DMD.
???
On 09/19/2014 04:59 PM, Andrei Alexandrescu wrote:
On 9/18/14, 10:53 PM, bearophile wrote:
Andrei Alexandrescu:
Wyatt:
(I wouldn't consider the cookie parameter a better solution; I would
consider it a wart.)
That's the right solution.
The cookie parameter is a ugly wart.
No. -- Andrei
On 09/20/2014 02:29 AM, Andrei Alexandrescu wrote:
On 9/19/14, 5:28 PM, Timon Gehr wrote:
On 09/19/2014 04:59 PM, Andrei Alexandrescu wrote:
On 9/18/14, 10:53 PM, bearophile wrote:
Andrei Alexandrescu:
Wyatt:
(I wouldn't consider the cookie parameter a better solution; I would
consider it a
On 09/20/2014 06:52 AM, Andrei Alexandrescu wrote:
On 9/19/14, 8:14 PM, Timon Gehr wrote:
To substantiate: It does the wrong thing (same typedef for same base
type) by default and doing the right thing (emulating nominal typing)
may require quite some effort in general (e.g. concatenate the
On 09/21/2014 09:05 AM, Daniel Murphy wrote:
"Tofu Ninja" wrote in message news:nwjquvwnetifhydfa...@forum.dlang.org...
On Saturday, 20 September 2014 at 23:07:16 UTC, Adam D. Ruppe wrote:
>> string results[](T) = "I have no idea what I'm doing";
>
> I agree that's just weird though, someone p
On 09/21/2014 07:29 AM, deadalnix wrote:
Free goodie: when you import, all symbol are resolved via the expected
import resolution mechanism. All ? No, the root package is imported in
the local scope.
foo(int a) {
import a.b.c;
// a is now a package and not the parameter a anymore.
}
For
On 09/21/2014 11:53 AM, Rainer Schuetze wrote:
It also references the issue why this has been changed pretty recently:
https://issues.dlang.org/show_bug.cgi?id=11257
I'm on the fence whether this is convenient or makes it too easy to
break const "guarantees". It seems strange that you can modif
On 09/21/2014 03:53 PM, H. S. Teoh via Digitalmars-d wrote:
I.e., this should work:
string foo(string text) {
import std.conv; // includes std.conv.text
return "";// but `text` is never referenced
}
but this should emit an error:
stri
On 09/21/2014 09:54 PM, Walter Bright wrote:
On 9/21/2014 5:55 AM, Timon Gehr wrote:
For local imports, DMD imports _all_ symbols into the local scope,
shadowing
anything that was there, which is plain broken (as Sӧnke's example
shows). BTW:
how do you suggest to treat the root package? I think
On 09/21/2014 10:08 PM, Walter Bright wrote:
On 9/21/2014 12:58 PM, Timon Gehr wrote:
On 09/21/2014 09:54 PM, Walter Bright wrote:
On 9/21/2014 5:55 AM, Timon Gehr wrote:
For local imports, DMD imports _all_ symbols into the local scope,
shadowing
anything that was there, which is plain broken
On 09/22/2014 12:17 AM, Andrei Alexandrescu wrote:
"vivid anecdote fallacy"
FWIW:
https://www.google.ch/?gws_rd=cr&ei=XVYfVIu7IcL1OYi7gMgH#q=%22vivid+anecdote+fallacy%22
On 09/21/2014 12:08 AM, Andrei Alexandrescu wrote:
My perception of this thread is that there's an abundance of that misleading
vividness
fallacy (http://en.wikipedia.org/wiki/Misleading_vividness). Rhetoric
techniques blow
the most trivial matters out of proportion and build to the foaming
co
On 09/22/2014 01:37 AM, deadalnix wrote:
On Sunday, 21 September 2014 at 20:05:57 UTC, Walter Bright wrote:
On 9/20/2014 10:29 PM, deadalnix wrote:
DMD does very bizarre things. I think I should write a DIP, but time
is always
running low...
Free goodie: when you import, all symbol are resolve
On 09/22/2014 03:26 PM, Daniel Murphy wrote:
"Timon Gehr" wrote in message news:lvmh5b$eo9$1...@digitalmars.com...
When was int x(T)=2; introduced?
At the same time as enum x(T) = 2; I think.
...
Is this documented?
Also, C-style array syntax would actually be string results(T)[] = "";.
On 09/22/2014 10:27 PM, deadalnix wrote:
On Monday, 22 September 2014 at 09:17:16 UTC, Walter Bright wrote:
It is depth first. It starts at the innermost scope, which is the
current scope. Somehow, we don't seem to be talking the same language :-(
Depth first in the sense, go from the inner t
On 09/23/2014 10:19 PM, monarch_dodra wrote:
As I said, local imports, IMO, should behave in all aspects as a global
import. It simply only exists during its scope, but is not actually any
more "internal" than the rest. If a local import creates a symbol
ambiguity, then it's ambiguous, and compi
101 - 200 of 1584 matches
Mail list logo
