date:20140618

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 you can expand upon.
 
 http://dpaste.dzfl.pl/55cb22153fcc
 
 Thanks for that link. Yes, that is close. I'd even feel reasonaly well
 about it if it was in phobos so everybody can use the mechanism
 consistently.

Pull requests are always welcome. ;-)


 It does not however, quite meet the mark of with ease.

Why not? You can just put it in its module and import it whenever you
need it.


 But it is possibly an acceptable hack around a shortcoming in the
 language.
 Comming from C++, it's not as though I'm not used to those.
 Just a shame to have to resort to it when D is so pretty close to
 getting rid of dirty hacks more or less completely.
[...]

I don't see it as a hack, much less a dirty one. The language was
designed precisely to allow implementing this kind of user-defined
extensions easily. In fact, there has been a recent trend to move things
*out* of the core language where a library implementation suffices.


T

-- 
Computers are like a jungle: they have monitor lizards, rams, mice, c-moss, 
binary trees... and bugs.

Re: Constant relationships between non-constant objects

2014-06-18 Thread Maxim Fomin via Digitalmars-d


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 chosen D over C++ for.


Cheers,
Seb


I believe this is wrong. First of all, if you want to keep 
relationship between objects, instead of thinking which feature 
can prevent it, consider not to try to break it in a first place.


Secondly, it is sometimes discussed how to write some idiomatic 
code per se, rather than to solve particular task.


Thirdly, if feature from one language does not do the same as 
similar feature from other language, does not mean that the 
feature/language is broken.


Lastly, taking into account that it was Walter decided to do so, 
says something.


Regarding your problem. Keeping relationship between two classes 
can be achieved by associative array, by inheriting from one 
class or by using examples above.

Re: A Perspective on D from game industry


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' than C/C++ as it doesn't have pointer 
aliasing (think
that C++ introduced restrict, which is the bread and butter of 
a HPC
language only in C++11, same for threading, still no vector 
types...)
for example. ISPC is a HPC language or Julia, Fortran, even 
Numpy if you

want, not D or C or C++
http://c0de517e.blogspot.in/2014/06/where-is-my-c-replacement.html?showComment=1402865174608#c415780017887651116



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 :)


http://blogs.msdn.com/b/vcblog/archive/2013/07/12/introducing-vector-calling-convention.aspx

Re: Constant relationships between non-constant objects

2014-06-18 Thread Jonathan M Davis via Digitalmars-d

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 case of
  const (preventing developer mistakes! Not optimization.)
 
  Cheers,
  Seb
 
  Yes. D does not provide head-const.
 
  Though I would disagree that it is the most important use-case
  for const.

 But can you agree that it is AN important use case?

It would be better to have it as an option, but in my experience, head-const
is close to useless, so while it might be nice to have upon occasion, not
having it isn't all that big a loss. I always thought that it was pretty
useless that Java provided head-const (especially because that's the _only_
kind of const that it has).

 If so, what was the rationale to not include a feature in D that has been
 used with great success in other languages? Don't get me wrong, I
 really like immutable and const and the fact that they are
 transitive. There are good use cases for this.

It comes down to the same reason that we have std.typecons.Rebindable to make
it so that you can have a non-const reference to a const object. The type
system doesn't really have the concept of a class, just a class reference.
When you say

MyClass c;

the type of MyClass is a reference to the class that's named MyClass rather
than being MyClass itself, and there's nowhere in the type system that makes
the distinction, because there's nowhere that you can even refer to a class
type without a reference to an object of that class type.

When const was first being worked on in D2, other options were explored with
regards to how to handle const, and for a short while we had a distinction
between head-const and tail-const when declaring variables of various types,
but it was ultimately decided that the result was just too complicated, and
the current route of using parens was introduced, which does lose us some
flexibility, but it gets us most of the way there while being much simpler.

However, I don't know think we ever really had head-const or tail-const
classes even then, because of how classes are represented in the compiler.
Walter attempted to rectify the problem multiple times but gave up on it,
since apparently, it's quite difficult, and he got sick of trying. At least
one major attempt has been made by another developer, but Walter didn't
approve of the way that it was done, so it never made it into the compiler or
the language (I don't know what the problems with it were though).

So, to fix this, we'd need a way (syntactically) to somehow indicate that a
class reference is head-const or tail-const without adding much complication
to the language, and there would have to be a major overhaul of how classes
are viewed by the compiler, which is enough of a pain that it's just never
been fully, successfully done.

So, we have std.typecons.Rebindable in order to get tail-const class
references, and elsewhere in this thread, Meta provided a similar wrapper to
give you head-const. However, no one has ever found head-const to be
important enough to put anything like that in Phobos. It's always the lack of
tail-const class references that folks complain about. You're the only person
I've ever seen who's complained about the lack of head-const.

- Jonathan M Davis

Re: Constant relationships between non-constant objects

2014-06-18 Thread Rikki Cattermole via Digitalmars-d


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 of the issues in C++ that I
would have chosen D over C++ for.

Cheers,
Seb


I believe this is wrong. First of all, if you want to keep relationship
between objects, instead of thinking which feature can prevent it,
consider not to try to break it in a first place.

Secondly, it is sometimes discussed how to write some idiomatic code per
se, rather than to solve particular task.

Thirdly, if feature from one language does not do the same as similar
feature from other language, does not mean that the feature/language is
broken.


+1


Lastly, taking into account that it was Walter decided to do so, says
something.

Regarding your problem. Keeping relationship between two classes can be
achieved by associative array, by inheriting from one class or by using
examples above.


There is also always things like property getter functions if you really 
really want to be pedantic about it.


class A {
this(B b) {
b_ = b;
}

private B b_;

@property B b() {
return b_;
}
}

class B {
string text;

this(string text) {
this.text = text;   
}
}

void main() {
import std.stdio;
A a = new A(new B(hi there));
writeln(a.b.text);
a.b.text = boo;
writeln(a.b.text);
}

In this case, literally no way to get access to b_ variable directly 
unless you are in the same module.


To prevent assignment within the same module, a wrapper would be needed 
as has been discussed.


Personally I wouldn't use code like this. But thats just me.

Re: Constant relationships between non-constant objects

2014-06-18 Thread Jonathan M Davis via Digitalmars-d

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 though I'm not used to those.
  Just a shame to have to resort to it when D is so pretty close to
  getting rid of dirty hacks more or less completely.
 [...]

 I don't see it as a hack, much less a dirty one. The language was
 designed precisely to allow implementing this kind of user-defined
 extensions easily. In fact, there has been a recent trend to move
 things *out* of the core language where a library implementation
 suffices.

It's certainly not a hack, and it's a good example of how we can do quite a
bit with the language without having to actually add to the language, but I
think that most of us agree that Rebindable is an undesirable solution, and
we'd welcome it if it could be done cleanly in the language. The problem is
that doing it in the language has proven to be incredibly difficult due to
how the compiler was written.

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 couldn't do it in the language itself.

- Jonathan M Davis

Re: A Perspective on D from game industry

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 post, which I've read with interest at the time.


Unfortunately I do think it gets abused, which clearly is not the 
book's fault, to the point that I'm persuaded it originated more 
bizantine, messy code than solved problems. I might though be 
biased by the fact I work in a very specific industry though.


The same in my mind goes for the GOF Patterns book (actually the 
patterns one is just bad, damaging and boring at the same time, 
it just renames existing language concepts and casts them in a OO 
mantle).


Certain concepts gained so much hype that people started applying 
them mindlessly. Crister Ericson write it well: 
http://realtimecollisiondetection.net/blog/?p=44 and 
http://realtimecollisiondetection.net/blog/?p=81


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 metaprogramming is not 
abused?


What would you think of stuff like this? 
http://www.boost.org/doc/libs/1_55_0b1/libs/geometry/doc/html/geometry/design.html 
(if you can share...)

Re: Swift does away with pointers == pervasive ARC

2014-06-18 Thread Jonathan M Davis via Digitalmars-d

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
  what's a DEC?
 
  I think he is probably talking about decrementing the ref count.

 Yes

Okay, thanks.

- Jonathan M Davis

Re: Tail pad optimization, cache friendlyness and C++ interrop


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 those programs that have 
generated unsafe features (instructions). Whether those unsafe 
features sit in a basic block that will never called is a 
different matter since @safe does not address that.


So yes, @safe is not equivalent to memory safety, it is 
equivalent to the absence of FEATURES that can lead to situations 
that aren't memory safe. But that is splitting hairs.


Absence of features such as unsafe instructions is a trivial 
property of the compiled program. A non trivial property is 
whether the program terminates, returns 0, rejects the input 
hello, etc.


and invoking Rice's theorem to this end is perfectly fine and 
does not suffer from any 'issues'.


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 bytes of RAM. You cannot do it 
for all TMs since they have unbounded storage.


Thus you can prove non-trivial properties such as whether a 
functions returns with 1, whether it accepts or rejects the input 
'0', etc. It might take a lot of time, but you can do it in a 
fixed amount of time. You cannot do it for TMs.


But this issue is simpler than that. Think about it this way: 
There are problems that have a solution, but it is provable 
impossible to solve analytically. You still can solve them 
numerically down to a specified precision.


I posit you can do the same with memory safety, as in: you can 
reject all unsafe programs and reduce the set of false positives 
to a marginal set of typical programs (which are written with 
memory safety in mind).

Re: A Perspective on D from game industry


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 still exercise a lot of control, we want to know
exactly what a statement does in terms of how it's executed.


It's a fair criticism.

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 
handle the increasing complexity of modern programs. Proper use of 
metaprogramming reduces complexity and reduces programming bugs. And yes, the 
price paid for that is you'll need to put more trust in the metaprogramming 
tools to do the right thing with your intention, just like modern programs now 
trust the compiler.

Re: Constant relationships between non-constant objects

2014-06-18 Thread Daniel Murphy via Digitalmars-d

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 this in the form of the 'final' storage class for 
variables.  I'm not sure why we got rid of it.

RFC: Value range propagation for if-else

2014-06-18 Thread Lionello Lunesu via Digitalmars-d


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 false-positive warnings given out by the fix to bug 259 by allowing 
code like this: if (signed  0  signed  unsigned) { .. }


Have a look at the branch:
https://github.com/lionello/dmd/compare/if-else-range

There, I've also added a __traits(intrange, expression) which returns 
a tuple with the min and max for the given expression. It's used in the 
test case as follows:



const i = foo ? -1 : 33;

if (i)
  static assert(__traits(intrange, i) == Tuple!(-1, 33));
else
{
  //static assert(i == 0); TODO
  static assert(__traits(intrange, i) == Tuple!(0, 0));
}

if (i == 33)
{
  //static assert(i == 33); TODO
  static assert(__traits(intrange, i) == Tuple!(33, 33));
}
else
  static assert(__traits(intrange, i) == Tuple!(-1, 32));

if (10 = i)
  static assert(__traits(intrange, i) == Tuple!(10, 33));
else
  static assert(__traits(intrange, i) == Tuple!(-1, 9));


It would be nice if this can be used by CTFE as well.

Destroy?

L.

Re: A Perspective on D from game industry

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 handle the increasing complexity of 
modern programs. Proper use of metaprogramming reduces 
complexity and reduces programming bugs. And yes, the price 
paid for that is you'll need to put more trust in the 
metaprogramming tools to do the right thing with your 
intention, just like modern programs now trust the compiler.


Mine is not a campaign to eliminate metaprogramming, not even OO. 
Nor the language post was a critique of D, Rust or Go.


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 few times now but it's really so 
outrageous I want to punch people in the face - also notice how 
after all that crap the example code manages to forget about 
http://en.cppreference.com/w/cpp/numeric/math/hypot)


Also on a language perspective I'd say that if certain things can 
be part of the type system instead of done via metaprogramming, 
that is much better (boost::lambda vs c++11 lambda) because it 
becomes standard, it can have a specific syntax to give meaning 
to certain statements, tools can recognize it and so on.

Re: Tail pad optimization, cache friendlyness and C++ interrop

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 the programs that are most certainly 
memory safe, and also single out those programs that have 
generated unsafe features (instructions). Whether those unsafe 
features sit in a basic block that will never called is a 
different matter since @safe does not address that.


So yes, @safe is not equivalent to memory safety, it is 
equivalent to the absence of FEATURES that can lead to 
situations that aren't memory safe. But that is splitting hairs.




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. In the situation of tail pad optimization, it is obviously 
not valid anymore and will cause memory corruption. The 
discussion then derailed to what is @safe, as the code is 
certainly @safe, but it is difficult to prove it is 
automatically) 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 rather than listing what is allowed and adding to 
the list when some construct are proven to be @safe).

Re: A Perspective on D from game industry


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 metaprogramming 
is not abused?




Everything is a cost/benefit ratio. In C++, template are very 
complex beasts, and because of things like SFINAE, small errors 
can backfire quite badly.


In D, template are both simpler and more capable. It is therefore 
rational to used them more in D than in C++. The cost benefit 
equilibrium is at a different place.


I agree that template are overused in some C++ codebase. On the 
contrary, I would probably use even more template if I had to 
port such code in D.

Re: A Perspective on D from game industry

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 so excited by pointless 
generalization, then some grow out of it (studying other 
languages also helps) but some never do.


We write a lot about powerful techniques and neat applications, 
but often forget to show the perils and tradeoffs.

Re: Tail pad optimization, cache friendlyness and C++ interrop


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


https://issues.dlang.org/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDkeywords=safe%2C%20keywords_type=allwordslist_id=41168query_format=advanced

Currently, there are zero bugzilla issues tagged with 'safe'. 
Please file bugzilla issues for which ones are discovered and 
tag them!


I don't even know what to answer to that. We are clearly talking 
past each other here, and I have no idea how to convey the 
message in a better way.

Re: Tail pad optimization, cache friendlyness and C++ interrop


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


https://issues.dlang.org/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDkeywords=safe%2C%20keywords_type=allwordslist_id=41168query_format=advanced

Currently, there are zero bugzilla issues tagged with 'safe'. Please file 
bugzilla issues for which ones are discovered and tag them!

Re: Constant relationships between non-constant objects


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 a condition,
perhaps == was meant?


I'd stronly argue for D getting that feature. If I can't 
express some of the most basic constructs in OOD in D, it 
really falls more into the category of a toy language for me.



Now, in the 19 years as a software developer,


When you are used to language A with feature X and you switch to
language B that lacks X, a very common programmer's fallacy is to
think you can't live with X or B is a toy language because it
lacks X. In reality languages are not a collection of features,
they are more like an ecology of features, where each part is
designed keeping in account the presence of most of the other
parts. So usually language B has features or tools that make up
for the lack of X, or X was too much costly to add to B. So when
you switch to use language B you need to adapt yourself and work
around the lack of X using what B offers.

Bye,
bearophile

Re: A Perspective on D from game industry


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 horrors of 
generalization?




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 repeated patterns ? Is 
there some part of the code that is growing in complexity ? Do 
part of the code rely on fragile hacks ? Is part of the code 
doing useless work ? etc...
 - If yes, refactor accordingly, either by adding new level of 
abstraction, but better, by changing the interface of some 
abstraction to better fit its actual usage (and not the you were 
thinking you'd get at first).


This allowed me to avoid creating useless abstraction, and push 
me to refine existing ones.


Especially C++ neophytes get so excited by pointless 
generalization, then some grow out of it (studying other 
languages also helps) but some never do.




I used to be like that :D

Re: Constant relationships between non-constant objects


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 couldn't do it in the language itself.


Often I have functions that take an array as argument, like this 
foo:


void foo(int[] arr) {}
void main() {}


In many cases I'd like to modify the array contents, but I'd like 
a way to tell the D type system that inside foo I don't want to 
change the length of the array arr, nor that I want to rebind the 
pointer. This is head-const and it's not useful to avoid bugs 
outside foo (because length and ptr of arr are values, so foo 
can't change their value at the calling point), it's useful to me 
to avoid modifying the array length by mistake inside foo:


void foo(int(const[]) arr) {}
void main() {}


So I'd like to use for array Head-constness. An advantage of this 
kind of constness is that it doesn't change the type system a 
lot, because the constness of the length+ptr of arr is not 
visible outside foo.


Bye,
bearophile

Re: A Perspective on D from game industry

2014-06-18 Thread Sean Cavanaugh via Digitalmars-d


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 :)


http://blogs.msdn.com/b/vcblog/archive/2013/07/12/introducing-vector-calling-convention.aspx



VectorCall is all about working the original x64 ABI that only lets you 
officially pass float and double point scalars around in the xmm 
registers.   vectors require writing a bunch of helper forceinline 
functions that always operate on pointers or references, as passing by 
value lacked vectorcall, and on x86 pass by value for xmm types won't 
even compile.


Ultimately the code ends up with calls to you have to call something 
like _mm_store_ps or _mm_stream_ps etc, those are the functions that 
take pointers, and you have to cast away volatile (and afaik restrict is 
ignored on them as well but you don't to cast it away).

Re: Constant relationships between non-constant objects

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

Re: A Perspective on D from game industry

2014-06-18 Thread xenon325 via Digitalmars-d

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:


You can do that with interfaces. Though there are problems:
1. built-in and value types
2. indirection

C# solved (1). Don't know if it's possible to solve both without 
templates.

Re: RFC: Value range propagation for if-else


I'd like a name like integral_range,


value_range seems better, more general.

Bye,
bearophile

Re: RFC: Value range propagation for if-else


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, exp) could work on core.checkedint 
values too, or it could be used by them to remove some overflow 
tests and increase their performance.




It's used in the test case as follows:


I presume your proposal allows this code to compile:

int x = 100;
void main() {
if (x = 0  x = ubyte.max) {
ubyte y = x;
}
}


If your proposal is extended to contracts, you can also write:


ubyte foo(immutable int x)
in {
assert(x = 0  x = ubyte.max);
} body {
return x;
}
void main() {}


Bye,
bearophile

Re: A Perspective on D from game industry


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 few times now but it's really so outrageous I want to


Thanks, that link is pure awesomeness in its awfulness!


punch people in the face - also notice how after all that crap the example code
manages to forget about http://en.cppreference.com/w/cpp/numeric/math/hypot)



Also on a language perspective I'd say that if certain things can be part of the
type system instead of done via metaprogramming, that is much better
(boost::lambda vs c++11 lambda) because it becomes standard, it can have a
specific syntax to give meaning to certain statements, tools can recognize it
and so on.


I disagree with that because it makes the language into a kitchen sink grab bag 
of features. It's better to put enabling features into the language and have the 
standard library define standard forms.

Re: A Perspective on D from game industry




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;
range.popFront();
}
return range;
}


http://en.wikipedia.org/wiki/Parametric_polymorphism

C++ Templates are more general than that, they do express this 
kind of polymorphism but that can be done without full 
metaprogramming (turing-complete ability of generating code at 
compile time). A bounded parametric type is better than templates 
(C++ concepts are an attempt to patch templates with bounds)


Also notice that really all this is expressible even in languages 
that have only dynamic polymorphism (subtyping) without 
performance penalties (YES REALLY).


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 because they are 
always inline, the compiler knows exactly what to call without 
indirections. But that's only WORSE than the indirect 
alternatives, because interfaces and pointers afford you the 
option not to resolve everything statically, but if you want you 
can always inline everything (put the implementation in headers) 
and the compiler will perfectly know that it can directly call a 
given function without overhead...

Re: A Perspective on D from game industry

2014-06-18 Thread ponce via Digitalmars-d


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 additional cost to use it, and I 
believe a huge one. But essentially it's hidden behind the daily 
challenges of specific domain X.

Re: Tail pad optimization, cache friendlyness and C++ interrop


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 by definition an unsafe feature, but a hypothetical 
cleartype(foo,…) is a safe feature. Imagine having a hypothetical 
IR that makes the unsafe/safe distinction, then you can have both 
memset and cleartype in that IR and transform them into memset at 
the lower level backend without causing problems for memory 
safety verification.


In the situation of tail pad optimization, it is obviously not 
valid anymore and will cause memory corruption.


But if you have cleartype() when you do tail pad optimization and 
turn it into memset a codegen then you are ok?


The discussion then derailed to what is @safe, as the code is 
certainly @safe, but it is difficult to prove it is 
automatically) 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 rather than listing what is allowed and 
adding to the list when some construct are proven to be @safe).


I don't disagree, I think the simplest thing to do is to have a 
hypothetical implied IR between the AST and the backend and 
accept safe features on that level.


I think people who care about @safe also will accept that some 
safe programs are rejected if it is easy to modify the code into 
something the compiler accepts. The compiler could even provide 
suggestions: (consider using cleartype() over memset() etc).

Re: RFC: Value range propagation for if-else

2014-06-18 Thread Lionello Lunesu via Digitalmars-d


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 traits return tuples, so it seemed like a good fit.


I presume your proposal allows this code to compile:

int x = 100;
void main() {
 if (x = 0  x = ubyte.max) {
 ubyte y = x;
 }
}


Yes, provided 'x' is immutable or const. It can be extended for mutable 
values as well, but then mutations/gotos must be tracked.



If your proposal is extended to contracts, you can also write:


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.


L.

Re: Tail pad optimization, cache friendlyness and C++ interrop

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

https://issues.dlang.org/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDkeywords=safe%2C%20keywords_type=allwordslist_id=41168query_format=advanced

Currently, there are zero bugzilla issues tagged with 'safe'. Please file
bugzilla issues for which ones are discovered and tag them!

I don't even know what to answer to that. We are clearly talking past each other
here, and I have no idea how to convey the message in a better way.

1. A long list of problems with @safe has been asserted, but I have not been
able to elicit any enumeration of them, so the extent of this problem is
completely unknown.

2. The definition of @safe in the spec is asserted to be utterly wrong, but no
corrected definition has been proposed.

3. A new approach to designing @safe has been proposed in vague terms, but
nothing specific and no offers of help to flesh it out.

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.

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
want things to happen, make them happen!

Re: A Perspective on D from game industry

2014-06-18 Thread Wanderer via Digitalmars-d


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 common in the industry.


Watch out for the little jab at Andrei :-P


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. Workable compiler (that doesn't crash on 20% of code it tries 
to compile :-P).


3. Stable, efficient and well-documented runtime library, 
including collection classes, IO, date/time, concurrency, GUI, 
graphics, sound etc.


4. A well-designed IDE written purely in D, which allows analysis 
and refactoring (like IntelliJ IDEA which is written in Java), 
free of course.


Believe me, after the step 4 is finished, MANY, if not most, of 
C++ and Java programmers will switch to D in no time. The 
language already provides many nice improvements, it's just not 
practical to use D yet (because RTL is still under development, 
no IDE etc).

Re: A Perspective on D from game industry

2014-06-18 Thread Daniel Murphy via Digitalmars-d


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 repeated patterns ? Is there 
some part of the code that is growing in complexity ? Do part of the code 
rely on fragile hacks ? Is part of the code doing useless work ? etc...
  - If yes, refactor accordingly, either by adding new level of 
abstraction, but better, by changing the interface of some abstraction to 
better fit its actual usage (and not the you were thinking you'd get at 
first).


This allowed me to avoid creating useless abstraction, and push me to 
refine existing ones.


This is exactly the approach I use and I've found the extra time spent on 
refactoring is well worth the time saved on not implementing things you 
don't need or that don't match the needs of the problem you're solving.
It does help that D is rather easy to refactor, and I'm much better at 
coming up with a good design after I've half-implemented it.

Re: A Perspective on D from game industry

2014-06-18 Thread Rikki Cattermole via Digitalmars-d


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 D. I can confirm
this sentiment is fairly common in the industry.

Watch out for the little jab at Andrei :-P


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. Workable compiler (that doesn't crash on 20% of code it tries to
compile :-P).


I've only found that when using CTFE + templates in a big way. Any other 
time.. its like 1% if that.



3. Stable, efficient and well-documented runtime library, including
collection classes, IO, date/time, concurrency, GUI, graphics, sound etc.

4. A well-designed IDE written purely in D, which allows analysis and
refactoring (like IntelliJ IDEA which is written in Java), free of course.



Believe me, after the step 4 is finished, MANY, if not most, of C++ and
Java programmers will switch to D in no time. The language already
provides many nice improvements, it's just not practical to use D yet
(because RTL is still under development, no IDE etc).


Something that I was thinking about, was about building the ecosystem up 
but not in a purely free way.
Duel licensing. Free for opensource, education and personal use. Not 
free for commercial use. Buy the IDE, buy the lot kind of deal.


I know this is a little like taboo in the D community, but it would help 
considerably I think.

Re: RFC: Value range propagation for if-else


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, then the body{} is the scope you look for.


Bye,
bearophile

Re: RFC: Value range propagation for if-else


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 :)

Re: RFC: Value range propagation for if-else

2014-06-18 Thread Sönke Ludwig via Digitalmars-d


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.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-18 Thread Joakim via Digitalmars-d


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 to them.

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 want things to 
happen, make them happen!


I largely agree with this assessment, but would also like to 
point out that while almost all programmers use compilers, very 
few know how to improve one.  You can help by fleshing out the 
dmd source guide so that it's better, then pointing people at it 
when they demand stuff from you: ;)


http://wiki.dlang.org/DMD_Source_Guide

I know, more work for you and the few dmd contributors, but you 
guys can help others get involved with better documentation for 
dmd.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-18 Thread Rikki Cattermole via Digitalmars-d


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 that.


Lol, I'd love to see your response to them.


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 want things to happen, make them happen!


I largely agree with this assessment, but would also like to point out
that while almost all programmers use compilers, very few know how to
improve one.  You can help by fleshing out the dmd source guide so that
it's better, then pointing people at it when they demand stuff from you: ;)

http://wiki.dlang.org/DMD_Source_Guide

I know, more work for you and the few dmd contributors, but you guys can
help others get involved with better documentation for dmd.


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 same goes with 
druntime. With a nice tutorial on how to set it all up on Windows/Linux ext.
Preferably with a nice automated means of, this is how we make a release 
build for platform x.


It'll go along way. It really would. And anyway it'll really show off 
the power of dub ;)


But in saying all this, I may want to learn to write my own compiler 
ext. I just don't have the knowledge and even getting into x86 
instruction encoding is head hurting alone as it stands.

Re: A Perspective on D from game industry

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 libraries are all that 
important. You need the basic ADTs that cover the holes in the 
language and some basic interfaces for streams.


The other stuff is too system specific and will come when the 
language is stable, capable and the runtime/GC is (commercial) 
production level. I think it is wrong for a system level language 
to create emulation layers in the runtime to even out OS 
differences (which only work for Posixy OSes). It is better to 
have semi-official OS-X bindings, Windows bindings, Posix 
bindings etc.


Look at the std C libs, which is pretty small, but quite obsolete 
due to its CLI/unix roots. std libs should never be obsolete due 
to changes in the environment.


4. A well-designed IDE written purely in D, which allows 
analysis and
refactoring (like IntelliJ IDEA which is written in Java), 
free of course.


The low hanging fruit is a community effort towards Eclipse.

Something that I was thinking about, was about building the 
ecosystem up but not in a purely free way.
Duel licensing. Free for opensource, education and personal 
use. Not free for commercial use. Buy the IDE, buy the lot kind 
of deal.


The basics have to be open source and free, meaning at least an 
Eclipse level IDE. Then you can have commercial fine tuned tools 
in addition to that (like a commercial vendor targeting PNACL, 
Windows or iOS).


I don't think dual licensing through dlang.org is a good idea. It 
erodes the perception of dlang.org being a foundation and turns 
it into freeloading company. That's usually bad if you want 
volunteers. SUN was quite nice with open source, but received 
almost no external contribution (compared to BSD/Linux). The 
original source should be perceived as altruistic. I think Walter 
Bright does that part quite well.


Better to have external entities do the commercial heavy lifting 
IMO.

Re: An LLVM bug that affect both LDC and SDC. Worth pushing for

2014-06-18 Thread Iain Buclaw via Digitalmars-d

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, deadalnix wrote:


 http://llvm.org/bugs/show_bug.cgi?id=20049

 Basically when you have a closure in a closure and the whole thing get
 inlined, LLVM mess up, which result in compiler not being able to
 optimize
 GC allocation away.

 Probably worth pushing for. It does probably affect other functional
 languages as well, but I didn't checked.



 This is the corresponding D code:
 https://github.com/deadalnix/SDC/blob/master/tests/test0156.d

 Correct?


 That code shouldn't create a GC allocated closure. :o)


 Change return bar to return bar and you got one possible candidate to
 trigger the bug.


Yeah, I did get that bit. I'm not sure of the optimisation though.

IMO, the closure/frame generation should occur *after* inlining.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-18 Thread Joakim via Digitalmars-d

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 same 
goes with druntime. With a nice tutorial on how to set it all 
up on Windows/Linux ext.
Preferably with a nice automated means of, this is how we make 
a release build for platform x.


I used this guide from the wiki some time back to start building 
dmd/druntime/phobos and run their tests, pretty easy:


http://wiki.dlang.org/Building_DMD

Non-Windows builds are very easy.  Windows builds require a bit 
too much manual configuration, I'll agree with that.


It'll go along way. It really would. And anyway it'll really 
show off the power of dub ;)


Daniel should stick his D frontend up there as a library, even if 
it isn't architected to be used as a library right now.  People 
will find ways to use it and his translated code will get some 
testing.

Re: A Perspective on D from game industry

2014-06-18 Thread Kagamin via Digitalmars-d

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 to another language?

Re: A Perspective on D from game industry

2014-06-18 Thread Kagamin via Digitalmars-d


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 because 
they are always inline, the compiler knows exactly what to call 
without indirections.


The processor needs to know what to call too, when it doesn't, it 
stalls. That means, the code executes slower.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-18 Thread Artur Skawina via Digitalmars-d

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 want things to happen, make them happen!

And most of those requests completely ignore language context, are
indiscriminately trying to copy or transplant other concepts, or give
a suboptimal answer to the wrong question. It's frustrating to even
just read them; I have several times considered unsubscribing, as 
watching things go in a wrong and very unproductive direction isn't
fun.

The one thing that /you/ could do, which would make the most difference,
is splitting up the compiler into a free frontend [1] and the non-free
rest. The current situation results in people avoiding looking at or
even going near DMD at all. 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 the risks involved when dealing with this
kind of mixed free and proprietary code within one repo are too high).

(JIC someone suggests working on the frontend via LDC/GDC trees - that
would inevitably result in a language fork eventually.)

artur

[1] the many problems with the artistic license are now gone, after the
switch to boost; at least the license itself is no longer an issue.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-18 Thread Matthias Bentrup via Digitalmars-d

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
adding to the list when new holes are discovered

https://issues.dlang.org/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDkeywords=safe%2C%20keywords_type=allwordslist_id=41168query_format=advanced

Currently, there are zero bugzilla issues tagged with 'safe'.
Please file

bugzilla issues for which ones are discovered and tag them!

I don't even know what to answer to that. We are clearly
talking past each other
here, and I have no idea how to convey the message in a better
way.

1. A long list of problems with @safe has been asserted, but I
have not been able to elicit any enumeration of them, so the
extent of this problem is completely unknown.

2. The definition of @safe in the spec is asserted to be
utterly wrong, but no corrected definition has been proposed.

3. A new approach to designing @safe has been proposed in vague
terms, but nothing specific and no offers of help to flesh it
out.

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.

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 want things to
happen, make them happen!

You two speak different languages here, I'll try to translate:

Basically deadalnix argues that memory safety cannot be checked
by a machine (there's a proof for that) and as @safe-ness can be
checked it obviously is not equivalent to memory safety. Further
*any* definition of @safe-ness that can be expressed by a finite
set of mathematical rules will not be equivalent to memory safety.

Then the big misunderstanding is the equivalence. Equivalence
means that

1) @safe implies memory-safe
2) !@safe implies !memory-safe

Clearly Walter is only talking about 1), and there is no reason
why you couldn't have a @safe-ness check that implies
memory-safety. It just won't be *equivalent*.

Re: A Perspective on D from game industry

2014-06-18 Thread Artur Skawina via Digitalmars-d

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 normal D code -- my
point was just that it doesn't have to be like that. But it's
something that can be hard to realize or even imagine, until one
sees the whole picture, with several language features playing
well together. Just like otherwise very experienced C++ programmers
often completely fail to appreciate certain D features, which only
really start to make sense in context and combination.

The difference that these two features made certainly surprised me;
suddenly I didn't had to write unreadable lambdas and mixins, the
code shrunk by a factor of ~three and became beautiful, even
properly syntax highlighted after a few tweaks to the editor settings.
It became very obvious that this is not just something-that-would-be-
-neat-to-have-but-D-has-so-many-other-more-important-problems, but that
it is a must-have. And it's really trivial do add - I did it /within/
the language, took ~100LOC; a proper built-in implementation wouldn't
be significantly harder.

But I'll shut up now, as apparently meta programming is considered 
harmful in certain industries, at least from what I read here. :)
Wouldn't want to scare anybody away.

I'll post in a new thread instead, in a few days, once I find the
time to construct a proper example and write at least a few sentences
explaining the syntax.

artur

Re: A Perspective on D from game industry

2014-06-18 Thread Manu via Digitalmars-d

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 his level of
 writing doesn't meet your standards. Furthermore, you unjustly called him a
 sophisticated idiot and narcissistic cunt. You've only shown yourself to
 be the ignorant one.


 Thanks for taking the time to look into my profile, I'm actually not as bad
 at English as it shows in my blog posts, but indeed is my second language
 and I'm not happy that I don't speak it quite as well as I'd like and I'm in
 the process even losing a bit my italian. I don't live in Italy anymore, I'm
 a rendering technical director for Activision|Blizzard.

Ah yeah. Do you work anywhere near a bloke named Rowan Hamilton? Say
gday for me if you do :)

Re: RFC: Value range propagation for if-else

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 for D!

Re: RFC: Value range propagation for if-else


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

Re: RFC: Value range propagation for if-else


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

Re: RFC: Value range propagation for if-else


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.

Re: RFC: Value range propagation for if-else


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,
 B upper = B.max,
 bool optional = false,
 bool exceptional = true)

defined at

https://github.com/nordlow/justd/blob/master/bound.d

where T is an integer type, that is an Ada-style integer range 
type.


It would of course be cool if DMD could support this for floating 
points aswell.


D range indexing/slicing should probably be builtin to the 
compiler.

Re: An LLVM bug that affect both LDC and SDC. Worth pushing for

2014-06-18 Thread David Nadlinger via Digitalmars-d

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?


David

Re: RFC: Value range propagation for if-else


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. But how?

Bye,
bearophile

Re: RFC: Value range propagation for if-else

2014-06-18 Thread Lionello Lunesu via Digitalmars-d


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 delivers.

Yet another sales point for D!


I submitted a pull request with the trait, without the if-else stuff! 
This should be faster to make it in.


https://github.com/D-Programming-Language/dmd/pull/3679

L.

Re: RFC: Value range propagation for if-else

2014-06-18 Thread Peter Alexander via Digitalmars-d


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. __traits
compiles and now __traits intrange), this VRP needs to be
precisely specified otherwise you end up with incompatible
differences between different compiler front ends. I don't want
to see code compiling in one compiler, but not another like we do
in C++ (and if we do, I'd like it to be minimized).

If this goes in, the mechanisms by which is works need to be
added to the spec.

Re: Tail pad optimization, cache friendlyness and C++ interrop


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 bytes of RAM. You cannot do 
it for all TMs since they have unbounded storage.


Thus you can prove non-trivial properties such as whether a 
functions returns with 1, whether it accepts or rejects the 
input '0', etc. It might take a lot of time, but you can do it 
in a fixed amount of time. You cannot do it for TMs.


Maybe I missed something in this discussion, but unless you are
not including jumps/loops in those N instructions, just because
the number of instructions and memory is bounded does not mean
you can prove (for arbitrary programs) that the program
terminates.

I hope I don't shoot myself in the foot by trying to come up with
a concrete example, but let me try. Consider the program to
calculate whether some point is part of the Mandelbrot set. The
program only requires a small and fixed amount of memory but for
some points it may iterate forever (practical fractal programs
set an iteration limit, but let's assume this one doesn't, for
the sake of the argument).

Adding the ?. null verification


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 a little frustrating when you see swift's ?. syntax 
notation, it would be a little more practical to be able to write


writeln(obj.member?.nested?.val);


Based on http://appventure.me/2014/06/13/swift-optionals-made-simple/


Any thoughts?

Re: Adding the ?. null verification

2014-06-18 Thread Kapps via Digitalmars-d


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)
{
writeln(obj.member.nested.val);
}
}
}

I have to admit it's a little frustrating when you see swift's 
?. syntax notation, it would be a little more practical to be 
able to write


writeln(obj.member?.nested?.val);


Based on 
http://appventure.me/2014/06/13/swift-optionals-made-simple/



Any thoughts?


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).

Re: Adding the ?. null verification


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, 
also with the - being replaced by . in D this is even more confusing 
when you switch a member from a pointer to a struct. The compiler could 
easily advise you to use the .? notation when you're moving in too deep 
into no man's land.

Re: Adding the ?. null verification

2014-06-18 Thread Lionello Lunesu via Digitalmars-d


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 a little frustrating when you see swift's ?. syntax
notation, it would be a little more practical to be able to write

writeln(obj.member?.nested?.val);


Based on http://appventure.me/2014/06/13/swift-optionals-made-simple/


Any thoughts?


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!

Re: Adding the ?. null verification


Etienne:


writeln(obj.member?.nested?.val);


What about an approach like Scala instead?

Bye,
bearophile

Re: Adding the ?. null verification


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) =
  try { block } catch {
case e: NullPointerException if e.getStackTrace()(2).getMethodName 
== $qmark = null

case e = throw e
  }

val a = ?(b.c.d.e)

Re: A Perspective on D from game industry

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)
  {
  if (range.front == element)
  break;
  range.popFront();
  }
  return range;
  }
 
 http://en.wikipedia.org/wiki/Parametric_polymorphism
 
 C++ Templates are more general than that, they do express this kind of
 polymorphism but that can be done without full metaprogramming
 (turing-complete ability of generating code at compile time).

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`;

I find this extremely awesome, actually. It's self-documenting (ctRegex
tells you it's a compile-time generated regex engine; the binary '!'
tells you it's a compile-time argument, the regex syntax is confined
inside the quoted ``-string, and doesn't spill out into language-level
operators, unlike C++'s Xpressive horror), and it's maximally efficient
because the matching engine optimization happens at compile-time,
whereas most regex libraries do the regex compilation at runtime.


[...]
 Also notice that really all this is expressible even in languages that
 have only dynamic polymorphism (subtyping) without performance
 penalties (YES REALLY).
 
 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 because they are always
 inline, the compiler knows exactly what to call without indirections.
 But that's only WORSE than the indirect alternatives, because
 interfaces and pointers afford you the option not to resolve
 everything statically, but if you want you can always inline
 everything (put the implementation in headers) and the compiler will
 perfectly know that it can directly call a given function without
 overhead...

This is a strawman argument. A template *can* be instantiated with base
class (or interface) arguments, and then you get *both* compile-time
*and* runtime polymorphism from the same template, i.e., the best of
both worlds.


T

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. 
-- Donald Knuth

Re: RFC: Value range propagation for if-else

2014-06-18 Thread Lionello Lunesu via Digitalmars-d


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 pre-condition and the argument is const, then
the body{} is the scope you look for.

Bye,
bearophile


That's a good point! I checked the DMD code and it seems doable. I can 
reuse the ConditionVisitor that I wrote for if-else.


Will play with it.

Re: A Perspective on D from game industry

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. Workable compiler (that doesn't crash on 20% of code it 
tries to compile :-P).


3. Stable, efficient and well-documented runtime library, 
including collection classes, IO, date/time, concurrency, GUI, 
graphics, sound etc.


4. A well-designed IDE written purely in D, which allows 
analysis and refactoring (like IntelliJ IDEA which is written 
in Java), free of course.


In my domain 4. is totally unnecessary, we use Visual Studio or 
we don't use an IDE on 99% of the projects. VisualD is the best 
thing that could have been done.

3. and 1. are quite unnecessary too, 2. of course is a must

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 can't live without 
and get adopted there and from there expand. E.G. JavaScript is 
horribly broken, but some people really needed to be able to put 
code client-side on web pages, so now JS is everywhere...

Re: RFC: Value range propagation for if-else

2014-06-18 Thread Lionello Lunesu via Digitalmars-d


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.

Re: Adding the ?. null verification


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;
string ident;
Type type;
AEntity typeInfo;
AEntity[] members; // for definitions
AEntity[] parameters; // if parameterized
...
}

It's very useful to descend through parts of a complex tree without 
adding plenty of bool checks


foreach (AEntity member; entity.members)
{
if (member.typeInfo !is null)
{
AEntity curr = member;
member.ident ~= member.typeInfo.ident;
curr = member.typeInfo;
while (curr.typeInfo !is null)
{
member.ident ~= . ~ curr.typeInfo.ident;
curr = curr.typeInfo;
}
}
}

Re: Adding the ?. null verification

2014-06-18 Thread Ary Borenszweig via Digitalmars-d


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 AEntity
{
 Module head;
 string ident;
 Type type;
 AEntity typeInfo;
 AEntity[] members; // for definitions
 AEntity[] parameters; // if parameterized
...
}

It's very useful to descend through parts of a complex tree without
adding plenty of bool checks

foreach (AEntity member; entity.members)
{
 if (member.typeInfo !is null)
 {
 AEntity curr = member;
 member.ident ~= member.typeInfo.ident;
 curr = member.typeInfo;
 while (curr.typeInfo !is null)
 {
 member.ident ~= . ~ curr.typeInfo.ident;
 curr = curr.typeInfo;
 }
 }
}


But if you don't add the bool checks you might get segmentation fault. 
Or am I missing something?

Re: A Perspective on D from game industry

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. Have you seen the horrors of generalization?

There's no need to call a hammer useless because (some) people insist on
using the wrong end to hit the nail. It's not the language's job to
educate people how to do things right; you should direct your complaints
at CS instructors instead. The language's job is to provide the
necessary tools to get the task done, whatever it may be. Excluding some
tools because some people don't know how to use them properly just
handicaps the language unnecessarily.


 Especially C++ neophytes get so excited by pointless generalization,
 then some grow out of it (studying other languages also helps) but
 some never do.
 
 We write a lot about powerful techniques and neat applications, but
 often forget to show the perils and tradeoffs.

So your complaints are really directed at how people use the language,
rather than the language itself. I don't think it's the language's job
to dictate to the user what to do -- Java tried to do that with OO, and
the result is so straitjacketed I feel like pulling out my hair every
time I use it. I find D far better in the sense of providing all the
tools to get the job done, and then STANDING BACK and letting me use the
tools as I see fit, instead of dictating a particular way of doing
things.

Now whether people are competent enough to use the language properly --
that's not really the concern of language design, it's a problem of
education. These are really two distinct issues. Using the lack of
education as evidence for poor language design -- I just don't follow
this kind of reasoning.


T

-- 
Life would be easier if I had the source code. -- YHL

Re: Adding the ?. null verification


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

Re: A Perspective on D from game industry



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 
technique from ever being used.


This is a strawman argument. A template *can* be instantiated 
with base
class (or interface) arguments, and then you get *both* 
compile-time
*and* runtime polymorphism from the same template, i.e., the 
best of

both worlds.


Which benefits? Given that if I call an inline function with a 
type that derives from an interface, the compiler knows the 
concrete type and doesn't need to go through the interface 
indirection, the performance of the dynamic approach is the 
same as the static, so why would you need the static at all?


But in C++ both approaches are actually very weak attempts at 
emulating better polymorphism. Templates are a loose, complex 
copy'n'paste engine that has no constraints on the types you 
instance them with. Interfaces give you the constraints, but 
forcing you to go through classes.


See some alternatives
- http://www.haskell.org/tutorial/classes.html
- http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora018.html

Re: Tail pad optimization, cache friendlyness and C++ interrop


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 discovered


https://issues.dlang.org/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDkeywords=safe%2C%20keywords_type=allwordslist_id=41168query_format=advanced

Currently, there are zero bugzilla issues tagged with 'safe'. 
Please file bugzilla issues for which ones are discovered and 
tag them!


I don't even know what to answer to that. We are clearly 
talking past each other here, and I have no idea how to convey 
the message in a better way.


Create a bugzilla issue to make everything unsafe and list there 
constructs you think can be defined as safe :)

Re: Tail pad optimization, cache friendlyness and C++ interrop

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 the risks involved when dealing 
with this
kind of mixed free and proprietary code within one repo are too 
high).


Wait what? Do you know a single person who decided to not work on 
DMD FE because of kind of formally (but not practically) non-free 
backend?

Re: Another way to do CTFE


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, 
effectively removing reflection out of the question.


Do I think including it in the language as opposed to build 
system is the deal breaker here? Not sure but unlikely. It 
improves mental context locality which is not important until 
this become a much more casual tool. And by the time this happens 
I'd like another design to be encouraged anyway.

Re: A Perspective on D from game industry


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 because 
they are always inline, the compiler knows exactly what to call 
without indirections. But that's only WORSE than the indirect 
alternatives, because interfaces and pointers afford you the 
option not to resolve everything statically, but if you want 
you can always inline everything (put the implementation in 
headers) and the compiler will perfectly know that it can 
directly call a given function without overhead...


I don't think it is that simple. What you speak about is only 
possible if compiler known full source code of all application 
including all possible dynamically loaded libraries. For compiled 
languages that puts such optimization out of practical 
consideration.

Re: A Perspective on D from game industry


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 can't 
live without and get adopted there and from there expand. E.G. 
JavaScript is horribly broken, but some people really needed to 
be able to put code client-side on web pages, so now JS is 
everywhere...


I think this is actually a flawed mentality that causes a lot of 
long-term problems to all programmers. By resisting to switch to 
languages simply because those are good we inevitably get to the 
point of switching because it is forced by some corporation that 
has bucks to create an intrusive ecosystem. And despite the fact 
language itself can be horrible no choice remains by then.

Re: A Perspective on D from game industry

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 important is being able 
to express complicated abstract relations between parts of your 
program and allowing compiler to both verify it and optimize 
based on that information. Boilerplate elimination without such 
verification is not even closely as tempting.

Re: RFC: Value range propagation for if-else


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 
language feature.


Bye,
bearophile

Re: Swift does away with pointers == pervasive ARC

2014-06-18 Thread whassup via Digitalmars-d

 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?

Re: Tail pad optimization, cache friendlyness and C++ interrop

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 listing what is not
allowed and
adding to the list when new holes are discovered

https://issues.dlang.org/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDkeywords=safe%2C%20keywords_type=allwordslist_id=41168query_format=advanced

Currently, there are zero bugzilla issues tagged with 'safe'. Please
file bugzilla issues for which ones are discovered and tag them!

I don't even know what to answer to that. We are clearly talking past
each other here, and I have no idea how to convey the message in a
better way.

Create a bugzilla issue to make everything unsafe and list there
constructs you think can be defined as safe :)

Everyone talks about it, but nobody does anything about it, so here goes
nothing:

https://issues.dlang.org/show_bug.cgi?id=12941

Obviously, I have no idea what should go in that list, so everyone who
cares about this issue, please chime in. Thanks!

P.S. I've also tagged a whole bunch of issues with 'safe'. It's just
based on a quick skim over all issues that turned up when I searched for
'safe', so I may have mistagged some, and missed others, but this is
just to get the ball rolling. Please fix wrong/missing tags if you find
them. :)

--
I'm still trying to find a pun for punishment...

Re: Adding the ?. null verification

2014-06-18 Thread Frustrated via Digitalmars-d


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)
{
writeln(obj.member.nested.val);
}
}
}

I have to admit it's a little frustrating when you see swift's 
?. syntax notation, it would be a little more practical to be 
able to write


writeln(obj.member?.nested?.val);


Based on 
http://appventure.me/2014/06/13/swift-optionals-made-simple/



Any thoughts?


Would be great! I think though, one could simplify it, you don't 
need multiple ?'s(one would do)


if (?obj.member.nested.val == null)
{
...
}

?object returns null if the object is null, even if it is 
dereferenced.


possibly a better syntax would be

if (??obj.member.nested.val == null)

If used as a rval one could have

auto x = ??obj.member.nested.val;

x is null if obj, obj.member, or obj.member.nested is null. Else 
obj.member.nested.val.


I'm just curious who is going to add the the code to D?

If you don't like ?? (confusing it with the null-coalescing 
operator) then what about ?*, *?, ?, ?, ???, etc...

prefix match of a regex and optimized dirEntries for regex search

2014-06-18 Thread Timothee Cour via Digitalmars-d

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 algorithmically) with a regex R' such that
L(R') L(p(R)) is awkward and inefficient, eg:

R='hello';
R'=`|h|he|hell|hello` = `(h(e(l(l(o)?)?)?)?)?`;

However thinking in terms of state machine this is much easier and
efficient.

It looks like this:
assert(hel.match(`hello\d+`.regex(p)); //p for prefix match

If there's interest in adding this I can prepare a pull request and we can
discuss more.

Example use case:
I wrote a function to search a file given a regex, and it is optimized to
prune directories early on if they fail to prefix match the regex, eg:

dirEntriesOptimized(`abc/folder_\d+/\w+\.cpp`)
when encountering `abc/bad_subfolder/` it will not recurse on this as it
fails the prefix regex match.

Re: Adding the ?. null verification


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)
{
writeln(obj.member.nested.val);
}
}
}

I have to admit it's a little frustrating when you see swift's 
?. syntax notation, it would be a little more practical to be 
able to write


writeln(obj.member?.nested?.val);


Based on 
http://appventure.me/2014/06/13/swift-optionals-made-simple/



Any thoughts?


Use a maybe monad :
Maybe(obj).memeber.nested.val

This doesn't require a language construct. Also, if null check 
are pervasive in your code, you probably have a problem somewhere.

Re: Adding the ?. null verification

2014-06-18 Thread Mattcoder via Digitalmars-d


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.

Re: Swift does away with pointers == pervasive ARC


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 make me think, doing RC but not when unwinding exception 
and backing the whole thing with a GC would probably be an 
interesting solution.

Re: A Perspective on D from game industry


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 think 
successful languages find one thing a community really can't 
live without and get adopted there and from there expand. E.G. 
JavaScript is horribly broken, but some people really needed 
to be able to put code client-side on web pages, so now JS is 
everywhere...


I think this is actually a flawed mentality that causes a lot 
of long-term problems to all programmers. By resisting to 
switch to languages simply because those are good we inevitably 
get to the point of switching because it is forced by some 
corporation that has bucks to create an intrusive ecosystem. 
And despite the fact language itself can be horrible no choice 
remains by then.


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.

Re: A Perspective on D from game industry