On 17/06/14 22:00, Bruno Medeiros wrote:
And perhaps rightly so, one could make a case that string mixins should
be used sparsely? We have to realize that string mixins are very useful,
but are a dirty hack that is a replacement for AST macros.
I fully agree, but that won't stop anyone from
Walter Bright:
https://github.com/D-Programming-Language/druntime/pull/839
Why aren't functions with ubyte/byte/short/ushort arguments
included?
--
Here Lionello Lunesu has suggested a __traits(valueRange,
expression) for built-in values:
On Tuesday, 17 June 2014 at 22:00:42 UTC, Tofu Ninja wrote:
On Tuesday, 17 June 2014 at 17:10:16 UTC, Mengu wrote:
and also the genius idea to post each talk seperately instead
of having a nice talks page on dconf.org and providing a link
for that. i'd understand the keynotes but for the rest
On 2014-06-17 05:38, Adam D. Ruppe wrote:
On Monday, 16 June 2014 at 22:23:31 UTC, Dicebot wrote:
I have found many of talks this year incredibly interesting for actual
D users but not as catchy for something that passes by. Also lot of
stuff has been discussed live in #d and ustream chat room.
On Tuesday, 17 June 2014 at 22:09:06 UTC, Joakim wrote:
Nobody paid attention to ruby for a decade, until David Hansson
built rails with it.
I am hoping the vibe.d will do that magic to D.
I need support for MS SQL Server to use it in production though.
On Wednesday, 18 June 2014 at 18:50:40 UTC, Jacob Carlborg wrote:
Downloading from youtube takes around a minute (HD quality).
Your internet must be a lot faster than mine :P I only get about
2 Mbps down so I like to get a lower quality file that downloads
faster but still plays reliably...
On 6/18/2014 2:43 AM, bearophile wrote:
Walter Bright:
https://github.com/D-Programming-Language/druntime/pull/839
Why aren't functions with ubyte/byte/short/ushort arguments included?
Because there is no ubyte/byte/short/ushort math in C, C++ or D. There is only
int/long math.
Walter Bright:
Because there is no ubyte/byte/short/ushort math in C, C++ or
D. There is only int/long math.
A little of ubyte math is present, perhaps for this you add
uinc, sinc, udec, sdec functions to core.checkedint that
support ubyte/byte/short/ushort types too:
void main() {
I find it impossible to even find the posts on HN. Within a few
hours of them being posted by Andrei, they are buried 4-5 pages
deep in the 'new' section with very few upvotes.
Last year I saw most of the talks (DConf13) on HN and
r/programming. This year I find them only on this forum
On Wednesday, 18 June 2014 at 01:26:16 UTC, Walter Bright wrote:
https://github.com/D-Programming-Language/druntime/pull/839
I think the mulu implementation is incorrect. There can be an
overflow even when r = 0. For example consider the int version
with x = y = 116.
On Wed, Jun 18, 2014 at 05:40:47AM +, Sebastian Unger via Digitalmars-d
wrote:
On Wednesday, 18 June 2014 at 04:38:25 UTC, Meta wrote:
On Wednesday, 18 June 2014 at 01:31:33 UTC, Sebastian Unger wrote:
There's no head const in D, but you can emulate it. This is a *very* basic
example that
On Wednesday, 18 June 2014 at 05:34:18 UTC, Sebastian Unger wrote:
So again, I believe, if D wants to play any role in major OO
software design and development, it will need to step up its
game. Especially in view of C++11 having addressed a number of
the issues in C++ that I would have
On Wednesday, 18 June 2014 at 03:28:48 UTC, Sean Cavanaugh wrote:
On 6/15/2014 4:34 PM, Joakim wrote:
He clarifies in the comments:
D is not 'high-performance' the same way as C and C++ are
not. Systems
is not the same as high-performance. Fortran always has been
more
'high-performance'
On Wed, 18 Jun 2014 02:26:24 +
Sebastian Unger via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Wednesday, 18 June 2014 at 02:15:21 UTC, Jesse Phillips wrote:
On Wednesday, 18 June 2014 at 01:31:33 UTC, Sebastian Unger
wrote:
Or has D really done away with the MOST important use
On 18/06/2014 6:05 p.m., Maxim Fomin wrote:
On Wednesday, 18 June 2014 at 05:34:18 UTC, Sebastian Unger wrote:
So again, I believe, if D wants to play any role in major OO software
design and development, it will need to step up its game. Especially
in view of C++11 having addressed a number
On Tue, 17 Jun 2014 22:58:24 -0700
H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Wed, Jun 18, 2014 at 05:40:47AM +, Sebastian Unger via
Digitalmars-d wrote:
But it is possibly an acceptable hack around a shortcoming in the
language.
Comming from C++, it's not as
On Wednesday, 18 June 2014 at 05:48:14 UTC, Andrei Alexandrescu
wrote:
On 6/16/14, 9:24 PM, c0de517e wrote:
Hi everybody. I'm Angelo Pesce, the author of the post on
c0de517e.
[snip]
Thanks for chiming in! -- Andrei
Hi Andrei! I had a little stab at your hugely influential book in
the
On Tue, 17 Jun 2014 18:35:37 -0700
Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 6/17/2014 4:51 PM, Tofu Ninja wrote:
On Tuesday, 17 June 2014 at 23:45:20 UTC, Jonathan M Davis via
Digitalmars-d wrote:
You probably explained it elsewhere and I just missed it, but
On Tuesday, 17 June 2014 at 22:44:00 UTC, Timon Gehr wrote:
As you know this will not single out _exactly_ the subset of
programs which is memory safe which is the claim I was arguing
against,
It will single out exactly the programs that are most certainly
memory safe, and also single out
On 6/17/2014 3:20 PM, c0de517e wrote:
The issue I have with metaprogramming (and overloading and some other similar
ideas) is that it makes a statement dependent on a lot of context, this is
tricky in a large team as now just reading a change doesn't really tell much.
Our is an industry where we
Sebastian Unger wrote in message
news:ebzakjopnllweizsi...@forum.dlang.org...
I have two classes A and B. Each object of class A is associated
with a particular object of class B. This association is not
supposed to change throughout the lifetime of the object of A.
I think D used to have
Hi,
I got this thing working and I think it's about time I get some comments
on it.
I've been wanting to extend Value Rang Propagation (VRE) for some time
now. Mostly because of the fix to the troublesome signed-unsigned
comparisons issue. Enabling VRE for if-else and will fix many of
the
On the other hand, we've already given up on a great deal of
knowing exactly what a statement does, even in C. How many of
us program in assembly anymore? How many of us can even make
sense of assembly code?
It is absolutely necessary to move to higher levels of
abstraction in order to
On Wednesday, 18 June 2014 at 06:35:01 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 17 June 2014 at 22:44:00 UTC, Timon Gehr wrote:
As you know this will not single out _exactly_ the subset of
programs which is memory safe which is the claim I was arguing
against,
It will single out exactly
On Wednesday, 18 June 2014 at 06:28:16 UTC, c0de517e wrote:
So I'm curious, do you think certain concepts went too far,
that we should educate against some hypes and abuses, or you
think that it's just my very partial view of the world and if
looking at the C++ community at large, template
It is absolutely necessary to move to higher levels of
abstraction in order to handle the increasing complexity of
modern programs.
And this is 100% right, but people should be educated about
premature abstraction. Have you seen the horrors of
generalization?
Especially C++ neophytes get
On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright wrote:
On 6/17/2014 11:50 PM, deadalnix wrote:
and the fact that @safe is defined backward (ie by listing
what is not allowed and
adding to the list when new holes are discovered
On 6/17/2014 11:50 PM, deadalnix wrote:
and the fact that @safe is defined backward (ie by listing what is not allowed
and
adding to the list when new holes are discovered
Sebastian Unger:
Just think bugs like
if (a = 3) ...
instead of
if (a == 3) ...
Not sure if this particular bug is possible in D, but that's
beside the point.
This bug is hard to do in D:
void main() {
int a = 3;
if (a = 3) {}
}
test.d(3,14): Error: assignment cannot be used as
On Wednesday, 18 June 2014 at 07:00:44 UTC, c0de517e wrote:
It is absolutely necessary to move to higher levels of
abstraction in order to handle the increasing complexity of
modern programs.
And this is 100% right, but people should be educated about
premature abstraction. Have you seen the
Jonathan M Davis:
Head-constness is something that's requested a _lot_ less
frequently
though (in fact, I think that this is the first time that I've
seen
it brought up), so if head-constness were the only issue, I
don't
think that many of us would be all that annoyed at the fact that
we
On 6/18/2014 1:05 AM, c0de517e wrote:
On Wednesday, 18 June 2014 at 03:28:48 UTC, Sean Cavanaugh wrote:
I had a nice sad 'ha ha' moment when I realized that msvc can't cope
with restrict on the pointers feeding into the simd intrinsics; you
have to cast it away. So much for that perf :)
the constness of the length+ptr of arr is not visible outside
foo.
So the mangling of the function foo could be the same as before.
Bye,
bearophile
On Wednesday, 18 June 2014 at 05:20:39 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Wed, Jun 18, 2014 at 02:18:47AM +, c0de517e via
Now you're talking polymorphism again, [...] and it's actually
not really metaprogramming, it's just
fancier typing.
Actually I was talking about templates:
I'd like a name like integral_range,
value_range seems better, more general.
Bye,
bearophile
Lionello Lunesu:
I've also added a __traits(intrange, expression) which
returns a tuple with the min and max for the given expression.
I'd like a name like integral_range, and perhaps it's better for
it to return a T[2] (fixed size array) instead of a tuple.
Such __traits(integral_range,
On 6/17/2014 11:54 PM, c0de517e wrote:
The intention is to make people -aware- of certain issues, to then make better
motivated choices and not end up thinking stuff like this is cool
http://www.boost.org/doc/libs/1_55_0b1/libs/geometry/doc/html/geometry/design.html
(sorry, I've linked this a
Actually I was talking about templates:
R find(R,T)(R range, T element)
if (isInputRange!R is(ElementType!R : T))
{
while (!range.empty)
{
if (range.front == element)
break;
On Tuesday, 17 June 2014 at 04:24:54 UTC, c0de517e wrote:
Hi everybody. I'm Angelo Pesce, the author of the post on
c0de517e.
Hi, I think the general idea of your post is 100% accurate, the
bigger risk for D is people not willing to move from C++. I work
in C++ full-time and it's an
On Wednesday, 18 June 2014 at 06:50:14 UTC, deadalnix wrote:
That isn't splitting hair. You are loosing track of the big
picture here. To come back to the original problem :
memset(foo, 0, typeof(foo).sizeof);
Walter mention that this is not corrupting memory and therefore
@safe.
memset is
On 18/06/14 15:53, bearophile wrote:
I've also added a __traits(intrange, expression) which returns a
tuple with the min and max for the given expression.
I'd like a name like integral_range, and perhaps it's better for it to
return a T[2] (fixed size array) instead of a tuple.
Most other
On 6/18/2014 12:05 AM, deadalnix wrote:
On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright wrote:
On 6/17/2014 11:50 PM, deadalnix wrote:
and the fact that @safe is defined backward (ie by listing what is not
allowed and
adding to the list when new holes are discovered
On Sunday, 15 June 2014 at 11:28:12 UTC, Peter Alexander wrote:
http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1
The arguments against D are pretty weak if I'm honest, but I
think it's important we understand what people think of D. I
can confirm this sentiment is fairly
deadalnix wrote in message news:qawhxkzqdgzjwylzr...@forum.dlang.org...
I call them architecture astronautes. To avoid that pitfall, I have a
adopted the following method :
- Do whatever you need to to get to the next step toward you goal.
- Make a pause and observe. Is there some
On 18/06/2014 8:21 p.m., Wanderer wrote:
On Sunday, 15 June 2014 at 11:28:12 UTC, Peter Alexander wrote:
http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1
The arguments against D are pretty weak if I'm honest, but I think
it's important we understand what people think of
Lionello Lunesu:
ubyte foo(immutable int x)
in {
assert(x = 0 x = ubyte.max);
} body {
return x;
}
Yeah, I wanted to support assert as well, but it doesn't
create a scope so it'll be a bit trickier to implement.
If you have an assert in a pre-condition and the argument is
const,
There, I've also added a __traits(intrange, expression) which
Very cool. With your new trait I can simplify and, in turn,
reduce compilation time for usages of
https://github.com/nordlow/justd/blob/master/bound.d
I'm looking forward to the merge :)
Am 18.06.2014 09:54, schrieb bearophile:
I'd like a name like integral_range,
value_range seems better, more general.
Bye,
bearophile
Or even better, valueRange, to be consistent with the general naming
convention.
On Wednesday, 18 June 2014 at 08:13:59 UTC, Walter Bright wrote:
From my perspective, it is like bug reports I'd often get for
the compiler that consisted solely of:
Your compiler doesn't work.
It's just not helpful. There's nothing I can do with that.
Lol, I'd love to see your response
On 18/06/2014 8:52 p.m., Joakim wrote:
On Wednesday, 18 June 2014 at 08:13:59 UTC, Walter Bright wrote:
From my perspective, it is like bug reports I'd often get for the
compiler that consisted solely of:
Your compiler doesn't work.
It's just not helpful. There's nothing I can do with
On Wednesday, 18 June 2014 at 08:27:57 UTC, Rikki Cattermole
wrote:
On 18/06/2014 8:21 p.m., Wanderer wrote:
3. Stable, efficient and well-documented runtime library,
including
collection classes, IO, date/time, concurrency, GUI, graphics,
sound etc.
I don't really think big standard
On 16 June 2014 20:37, deadalnix via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 16 June 2014 at 19:18:29 UTC, Iain Buclaw via Digitalmars-d
wrote:
On 16 June 2014 17:31, safety0ff via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 16 June 2014 at 06:09:28 UTC,
On Wednesday, 18 June 2014 at 09:16:32 UTC, Rikki Cattermole
wrote:
From my experience, one of the reasons I haven't had much to do
with the development of dmd is simply to compile dmd, druntime
is not as straight forward as it could be.
All I can say is with ddmd make it compilable with dub
On Tuesday, 17 June 2014 at 03:16:16 UTC, Caligo via
Digitalmars-d wrote:
My rant wasn't about his lack of fluency in the English
language. You
only learn once what a sentence is, and the concept translates
over to
most other natural languages.
How would you translate an arbitrary sentence
On Wednesday, 18 June 2014 at 07:58:57 UTC, c0de517e wrote:
People think that implementing interfaces is for some reason
inherently slower than templates, the same they believe
function pointers are slower than functors. It's FALSE. The
ONLY reason why templates and functors can be faster is
On 06/18/14 10:14, Walter Bright via Digitalmars-d wrote:
Also, D is a collaborative effort. If there's an issue that engages your
interest, step up and help out. I simply cannot do everything. This n.g. is
full of you should do this, you should do that largely directed at me. You
guys
On Wednesday, 18 June 2014 at 08:13:59 UTC, Walter Bright wrote:
On 6/18/2014 12:05 AM, deadalnix wrote:
On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright
wrote:
On 6/17/2014 11:50 PM, deadalnix wrote:
and the fact that @safe is defined backward (ie by listing
what is not
allowed and
On 06/17/14 22:15, Walter Bright via Digitalmars-d wrote:
On 6/17/2014 6:12 AM, Artur Skawina via Digitalmars-d wrote:
immediately realized that he now does not want to live w/o this
functionality)
I don't think I can take that kind of pressure!
I was responding to text editor sees only
On 18 June 2014 08:27, c0de517e via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Given that he lives in Italy, it's safe to assume that English is not his
first language. But rather than consider what he has to say or dispute his
arguments, you completely dismissed his point of view because
Very cool. With your new trait I can simplify and, in turn,
reduce compilation time for usages of
Actually, if I'm not mistaken, with this trait, we can inhibit
range value range checking in run-time when and get all the
benefits Ada range types currently delivers.
Yet another sales point
Nordlöw:
Actually, if I'm not mistaken, with this trait, we can inhibit
range value range checking in run-time when and get all the
benefits Ada range types currently delivers.
I'd like to see and discuss how this could happen.
Bye,
bearophile
I'd like to see and discuss how this could happen.
Certainly! I'm available later on this evening at, say, 20.00 CET.
/Per
On Wednesday, 18 June 2014 at 13:12:19 UTC, Nordlöw wrote:
D range indexing/slicing should probably be builtin to the
compiler.
Correction: I mean *inhibiting range checking for array slices*
should be built into the compiler.
On Wednesday, 18 June 2014 at 13:00:51 UTC, bearophile wrote:
I'd like to see and discuss how this could happen.
Note that my discussion so far is about inhibiting run-time
checknig of the value range of
struct Bound(T,
B = T, // bounds type
B lower = B.min,
On Wednesday, 18 June 2014 at 09:29:14 UTC, Iain Buclaw via
Digitalmars-d wrote:
Yeah, I did get that bit. I'm not sure of the optimisation
though.
IMO, the closure/frame generation should occur *after* inlining.
How would that work if your inliner operates on some
language-independent IR?
Nordlöw:
Note that my discussion so far is about inhibiting run-time
checknig of the value range of
struct Bound(T,
B = T, // bounds type
B lower = B.min,
B upper = B.max,
bool optional = false,
bool exceptional = true)
OK.
On 18/06/14 20:46, Nordlöw wrote:
Very cool. With your new trait I can simplify and, in turn, reduce
compilation time for usages of
Actually, if I'm not mistaken, with this trait, we can inhibit range
value range checking in run-time when and get all the benefits Ada range
types currently
On Wednesday, 18 June 2014 at 06:40:21 UTC, Lionello Lunesu wrote:
I got this thing working and I think it's about time I get some
comments on it.
This is really cool. Good job!
One thing we need to be careful with is how this is specified.
Because of all the compile time introspection (e.g.
On Wednesday, 18 June 2014 at 06:35:01 UTC, Ola Fosheim Grøstad
wrote:
Not really, you can prove termination for all programs with 3
instructions and 3 bytes of RAM. You can do it for all programs
with 4 instructions and 4 bytes of RAM. You can do it for all
programs with N instructions and N
I find myself often repeating this boilerplate:
if (obj.member !is null)
{
if (obj.member.nested !is null)
{
if (obj.member.nested.val !is null)
{
writeln(obj.member.nested.val);
}
}
}
I have to
On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
I find myself often repeating this boilerplate:
if (obj.member !is null)
{
if (obj.member.nested !is null)
{
if (obj.member.nested.val !is null)
{
C# is getting the same syntax, and I remember there being some
discussion about it here. It's somewhat useful I suppose, though I think
it's made significantly more useful in C# with 'a ?? b' (a if a is not
null, else b).
I've seen too many bugs where you end up dereferencing a null pointer,
On 18/06/14 23:42, Etienne wrote:
I find myself often repeating this boilerplate:
if (obj.member !is null)
{
if (obj.member.nested !is null)
{
if (obj.member.nested.val !is null)
{
writeln(obj.member.nested.val);
}
}
}
I have to admit it's
Etienne:
writeln(obj.member?.nested?.val);
What about an approach like Scala instead?
Bye,
bearophile
On 2014-06-18 11:55 AM, bearophile wrote:
Etienne:
writeln(obj.member?.nested?.val);
What about an approach like Scala instead?
Bye,
bearophile
You mean like this?
http://stackoverflow.com/questions/1163393/best-scala-imitation-of-groovys-safe-dereference-operator
def ?[A](block: = A)
On Wed, Jun 18, 2014 at 07:58:56AM +, c0de517e via Digitalmars-d wrote:
Actually I was talking about templates:
R find(R,T)(R range, T element)
if (isInputRange!R is(ElementType!R : T))
{
while (!range.empty)
{
On 18/06/14 16:28, bearophile wrote:
Lionello Lunesu:
ubyte foo(immutable int x)
in {
assert(x = 0 x = ubyte.max);
} body {
return x;
}
Yeah, I wanted to support assert as well, but it doesn't create a
scope so it'll be a bit trickier to implement.
If you have an assert in a
My opinion: if you want D to smoothly replace both C++ and
Java, simply do the following:
1. Sane language specification (which doesn't allow a slice of
a stack-allocated array to escape to other part of a program,
doesn't allow an object to contain garbage under ANY
circumstances etc).
2.
On 18/06/14 16:42, Sönke Ludwig wrote:
Or even better, valueRange, to be consistent with the general naming
convention.
That's what I ended up calling it.
I want non-null in the type system! To put a nullable reference into a
non-null variable you need to check first, but from then on the compiler
can ensure it's never null!
That would be great but useless for my situation involving some complex
AST's
class AEntity
{
Module head;
On 6/18/14, 1:17 PM, Etienne wrote:
I want non-null in the type system! To put a nullable reference into a
non-null variable you need to check first, but from then on the compiler
can ensure it's never null!
That would be great but useless for my situation involving some complex
AST's
class
On Wed, Jun 18, 2014 at 07:00:43AM +, c0de517e via Digitalmars-d wrote:
It is absolutely necessary to move to higher levels of abstraction in
order to handle the increasing complexity of modern programs.
And this is 100% right, but people should be educated about premature
abstraction.
But if you don't add the bool checks you might get segmentation fault.
Or am I missing something?
In D all pointers are zero-filled on initialization so it counts as a
bool for me and null is the same as if you had a *.init
You're talking about compile-time codegen? Like D's ctRegex
perhaps?
import std.regex;
// Statically generates a regex engine that matches the given
// expression.
auto r = ctRegex!`(a+b(cd*)+)?z`;
Looks nifty. As I said it's not that I want to ban a given
On Wednesday, 18 June 2014 at 07:05:13 UTC, deadalnix wrote:
On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright wrote:
On 6/17/2014 11:50 PM, deadalnix wrote:
and the fact that @safe is defined backward (ie by listing
what is not allowed and
adding to the list when new holes are
On Wednesday, 18 June 2014 at 11:09:14 UTC, Artur Skawina via
Digitalmars-d wrote:
The number of potential contributors is
already low enough, and the fuzzy licensing situation drives
away the
most valuable ones (since those will often be the ones which
treat the
legal aspects seriously and
On actual topic.
Do I think it is practical approach and has benefits over
existing situation? Definitely yes.
Do I think it is the right design with a more idealized
infrastructure? No. As Dmitry has mentioned it has huge flaw of
not being able to use template alias and type arguments,
On Wednesday, 18 June 2014 at 07:58:57 UTC, c0de517e wrote:
People think that implementing interfaces is for some reason
inherently slower than templates, the same they believe
function pointers are slower than functors. It's FALSE. The
ONLY reason why templates and functors can be faster is
On Wednesday, 18 June 2014 at 16:19:25 UTC, c0de517e wrote:
But as I wrote I doubt that people will think at a point that
yes, now D is 100% a better version of C++/Java/younameit,
let's switch. I don't think it's how things go, I think
successful languages find one thing a community really
Also I think all this discussion about template and generics
totally misses the point about meta-programming. It is not about
just code generation or replacing few type declarations, main
thing is compile-time reflection. The fact we use templates is
just a mere implementation details. What
Lionello Lunesu:
Will play with it.
And later you look at other things, like post-conditions:
int foo()
out(result) {
assert(result = 0 result = ubyte.max);
} body {
return 10;
}
void main() {
ubyte x = foo();
}
And slowly D Contract Programming starts to become a grown-up
Doesn't Nimrod do deferred referencing counting(with backup
cycle detection). Stack references don't need to DEC/INC. Do
conservative stack scan during collection. Nimrod doesn't have
D's GC issues, why not just do that?
On Wed, Jun 18, 2014 at 04:39:27PM +, Dicebot via Digitalmars-d wrote:
On Wednesday, 18 June 2014 at 07:05:13 UTC, deadalnix wrote:
On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright wrote:
On 6/17/2014 11:50 PM, deadalnix wrote:
and the fact that @safe is defined backward (ie by
On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
I find myself often repeating this boilerplate:
if (obj.member !is null)
{
if (obj.member.nested !is null)
{
if (obj.member.nested.val !is null)
{
I made a simple modification to std.regex to allow an option to prefix
match a regex.
Formally, if L(R) is the language recognized by a regex R, the language
recognized by prefix matching of R is:
L(p(R)) = prefix(L(R)) = {u : uv in L(R) for some v}
Trying to come up (by hand or
On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
I find myself often repeating this boilerplate:
if (obj.member !is null)
{
if (obj.member.nested !is null)
{
if (obj.member.nested.val !is null)
{
On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
it would be a little more practical to be able to write
writeln(obj.member?.nested?.val);
If one of these: member, nested or val == null, what will happen
with writeln()? It will print null or it will be avoided?
Matheus.
On Wednesday, 18 June 2014 at 17:08:25 UTC, whassup wrote:
Doesn't Nimrod do deferred referencing counting(with backup
cycle detection). Stack references don't need to DEC/INC. Do
conservative stack scan during collection. Nimrod doesn't have
D's GC issues, why not just do that?
Ho, that
On Wednesday, 18 June 2014 at 16:55:53 UTC, Dicebot wrote:
On Wednesday, 18 June 2014 at 16:19:25 UTC, c0de517e wrote:
But as I wrote I doubt that people will think at a point that
yes, now D is 100% a better version of C++/Java/younameit,
let's switch. I don't think it's how things go, I
On Wednesday, 18 June 2014 at 18:17:03 UTC, deadalnix wrote:
This is, but that's how it works nevertheless. You don't
succeed by arguing what the reality should be, but by accepting
what it is and act accordingly.
Being ashamed of it instead of glorifying such attitude is one
way to motivate
1 - 100 of 253 matches
Mail list logo
