Re: Does D have too many features?

[akaz]

It's hard to grep for (since with is
used in comments quite often),


Try to search for "with("  or "with\s(", that are less common 
in normal text.




There is no tool (maybe the compiler could provide such a tool) 
to remove all comments?


That way, you could do:

cat file.d | tool | grep whatever

Re: Const/Shared/Immutable anomalies in D that should be fixed

[Chris Cain]

On Thursday, 3 May 2012 at 06:00:58 UTC, Mehrdad wrote:
I believe all of these static assertions (and some variants 
thereof) should pass, due to the semantics of const, immutable, 
and shared.


...

Do people agree?


This doesn't even pass:
static assert(is(Immutable == Immutable));

The straightforward answer to this is that you really ought to 
have a main method :-)


import std.stdio;

immutable struct Immutable {}
const struct Const {}
shared struct Shared {}

void main() {
static assert(is(Immutable == immutable(Immutable)));
static assert(is(Immutable == const(Immutable)));
static assert(is(Immutable == shared(Immutable)));
static assert(is(Const == const(Const)));
//static assert(is(Const == shared(Const))); // Doesn't pass
static assert(is(Shared == shared(Shared)));
}

Also, what exactly is the difference between declaring a struct 
as immutable or as const? Aren't they unmodifiable either way?


Since const != shared, that's probably the main difference. IMO, 
I'd probably never see a point to making a const struct, so I'd 
prefer to always declare it immutable.

Re: Const/Shared/Immutable anomalies in D that should be fixed

[Chris Cain]

On Thursday, 3 May 2012 at 07:45:53 UTC, Chris Cain wrote:
The straightforward answer to this is that you really ought to 
have a main method :-)

...


Well, I just updated DMD to 2.059 (from 2.058) and lo and behold, 
this doesn't pass for the new version. Interesting. And 
apparently static asserts can now occur outside of a scope (must 
have been a fixed bug).


That said, I'm receptive to the change because I don't see a use 
case for the original behavior and I buy Mr. Davis' explanation.


Plus this:
void main() {
immutable(Immutable) a;
Immutable b;
static assert(!is(typeof(a) == typeof(b));
}
would fail with the old behavior, even though they are clearly 
distinct.


And of course is(typeof(anImmutable) == shared) is also false 
with the new version.

Re: D3 is potentially damaging

[James Miller]

On Wednesday, 2 May 2012 at 01:11:52 UTC, Alex Rønne Petersen 
wrote:

On 02-05-2012 03:08, ixid wrote:
The idea of D3 is a worrying one- it suggests a number of 
things that
would not be good for the success and adoption of the 
language. That the
language is experimental and more of a pet project, that D2 
has a
shelf-life and will be abandoned. I can see D going in two 
directions:
it can gradually grow and progressively gain areas where it's 
the
standard choice or it will be a fairly small community of fans 
of an
eternal language project. Python 2 and 3 has been a very messy 
split,
while languages with a greater sense of continuity do better 
for it in
my view, having one standard version of that language. 
Breaking changes
may be desirable but I don't think labelling that as v2/v3 is 
a good

idea, make it one thing with one suggested version.


I agree wholeheartedly. This whole "D3" excuse for not fixing 
design issues in the language is going to hurt us in the long 
run.




What are the aims of D3 that aren't aims of D2? What could be 
done then
that can't be done now? Wouldn't it be better to make breaking 
changes

sooner rather than later?


Yes and no. In theory, it's good to stabilize the language now 
and make a new version of it later which has breaking changes. 
In practice, that's annoying as hell. We've already seen how 
slow the transition from D1 to D2 is (not was; it's still 
happening!). D2 to D3 is going to be even slower (see in 
particular your Python 2 vs 3 example) simply because more and 
more people are going to be using D2 and therefore can't afford 
to port their applications to D3.


Honestly I think that the big problem going from D1 -> D2 was the 
issues with Tango. Hell, Tango in general seemed to just cause 
problems, what with the incompatible runtime and all.


D3 would be fine, iff it was easy to port D2 across and easy to 
continue using D2 code. A big problem with Python2 -> Python3 is 
the fact that it is a nightmare to have both running side-by-side.


I don't really think that D3 is a good idea, it would probably be 
better to gradually deprecate code going forward and replace the 
broken syntax and non backwards-compatible code.


Another useful could be to have a pragma(version, 2) so the 
compiler compiles with version 2 rules, no porting needed, just a 
single line near the top.


--
James Miller

Re: How can D become adopted at my company?

[Don Clugston]

On 30/04/12 01:03, Manu wrote:

On 30 April 2012 01:24, Tove mailto:t...@fransson.se>> wrote:

On Sunday, 29 April 2012 at 22:13:22 UTC, Manu wrote:

Is it technically possible to have a precise GC clean up all
unreferenced
memory in one big pass?


yes, but unless it's also moving/compacting... one would suffer
memory fragmentation... so I would imagine TempAlloc is a better fit?


In some cases I'm comfortable with that type of fragmentation (large
regularly sized resources), although that leads me to a gaping hole in
D's allocation system...


There is no way to request aligned memory. I can't even specify an
alignment on a user type and expect it to be aligned if I create one on
the stack, let alone the heap >_<
It seems I can request alignment for items within a struct, but I can't
align the struct its self. In addition, a struct doesn't inherit the
alignment of its aligned members, so the struct is allocated unaligned,
and the aligned member fails its promise anyway.


Bug 2278.

Re: Oddness with C binding

[Shahid]

I was blocked by Issue 5570 (DMD64), here was the progress I made before 
giving up https://gist.github.com/1131642

How to modify an element in a range/collection using its member function?

[Jens Mueller]

Hi,

in Phobos opIndex returns a copy due to the reasons outlined in TDPL p.
378 (hiding the storage). Even though I find the argumentation
convincing and opIndexAssign/opIndexOpAssign usually makes the design
sound I ran into surprises when using member functions.
I use the Zip the range which has the same behavior, i.e. return a copy.
Consider a random-access range/container R of say 10 points.

auto c = R!Point(10);

If Point has member functions you naturally write buggy code as I did
(operating on a temporary Point).
c[2].changePointSomehow();

The work around is
auto tmp = c[2];
tmp.changePointSomehow();
c[2] = tmp;
which does not look good to me. Simply things should be simple.
swap won't work as changePointSomehow() does not return the modified
Point.

Should std.range.Zip be an exception and return by reference? Because it
actually does not store anything. I don't like this as Zip may perform
some optimization for indexing.

What is a good solution when using member functions on a
range's/container's element?

Note, the problem only applies when storing structs because classes
behave like references.

Jens

Re: An observation

[Tobias Pankrath]

Not that I'm advocating Mutt, but I do recommend taking the 
time to
learn to use a threading mail/news reader. It will help you 
keep up with
very high traffic mailing lists/forums, and not just the D 
forums. (D's
forums are relatively tame, comparatively speaking. I've been 
on mailing
lists where traffic is measured in units of hundreds per day. 
And I used
to be subscribed to several of them. Never had a problem 
keeping up.

Just delete tree whenever it's tl;dr. :-))



Does the D newsgroup have broken threading in mutt? In my client
threading breaks often because some answers starts new thread
etc. makes the hole thing useless.

Re: How to modify an element in a range/collection using its member function?

[Peter Alexander]

I don't think that opIndexAssign/opIndexOpAssign were ever a good 
idea. Yeah, it works fine when all you are doing is x[i] = y, but 
that doesn't scale, as you have found out. It's short-sighted.


x[i] is an L-value for arrays, so it should be for everything 
else where it makes sense. Consistency is paramount.


I know C++ had the problem with std::map where x[i] would 
construct an entry when x[i] didn't exist, but that was due to a 
bad design decision. Indexing should never perform an insertion. 
Force users to use an 'insert' function to add elements and 
indexing should only work when the key is found (throw an 
exception otherwise). Again, it's a matter of consistency. 
Accessing x[10] of a 5-element array doesn't expand the array, so 
accessing x["foo"] of an empty map shouldn't expand the map.


Am I missing something here?

Re: How to modify an element in a range/collection using its member function?

[Chris Cain]

On Thursday, 3 May 2012 at 10:03:55 UTC, Jens Mueller wrote:

What is a good solution when using member functions on a
range's/container's element?

Note, the problem only applies when storing structs because 
classes

behave like references.


I think in this case, it might make sense to store pointers to 
structs.


So,

auto c = R!(Point*)(10);

OR

alias Point* PointRef;
auto c = R!PointRef(10);


Let me know if there's something wrong with this approach.

Windows batch file to compile D code

[Iain Staffell]

Hi all.

I have been trying (quite badly) to get started with D for a 
while.


On my first attempt I gave up before even compiling Hello World, 
because it was too difficult to find out how to even compile a 
program in Windows.  (I know.. I said I was bad at this..)


Second time around I tried harder, and wrote a Windows batch file 
to make compiling and running my code easier.  No messing around 
with PATH variables or things like that, too difficult.


I have been playing around with this for a year or so now, and 
thought it might be useful to someone else trying to learn D.  So 
here is a batch file that will automatically compile and run your 
D code.


If you're interested: save http://wogone.com/code/D2.BAT.TXT to 
your computer, rename to D2.BAT, then run D2 from a command 
prompt for further instructions.


Hope someone finds it useful, and not too buggy!  Any comments or 
improvements are more than welcome.

Re: Windows batch file to compile D code

[David]

Am 03.05.2012 14:31, schrieb Iain Staffell:

Hi all.

I have been trying (quite badly) to get started with D for a while.

On my first attempt I gave up before even compiling Hello World, because
it was too difficult to find out how to even compile a program in
Windows. (I know.. I said I was bad at this..)

Second time around I tried harder, and wrote a Windows batch file to
make compiling and running my code easier. No messing around with PATH
variables or things like that, too difficult.

I have been playing around with this for a year or so now, and thought
it might be useful to someone else trying to learn D. So here is a batch
file that will automatically compile and run your D code.

If you're interested: save http://wogone.com/code/D2.BAT.TXT to your
computer, rename to D2.BAT, then run D2 from a command prompt for
further instructions.

Hope someone finds it useful, and not too buggy! Any comments or
improvements are more than welcome.

rdmd? http://dlang.org/rdmd.html

Re: Does D have too many features?

[Don Clugston]

On 01/05/12 00:33, Timon Gehr wrote:

On 04/30/2012 11:28 PM, bearophile wrote:

Walter:


The first thing to emphasize is that NONE of this will happen for D2.
The emphasis on D2 is fixing implementation and toolchain issues.
Breaking existing code is off the table unless we are pretty much
forced to in order to fix some other more important issue.


But you need to keep into account that D2 is still a not widely used
language. So deprecating some things now will cause far less troubles
than doing it in D3 some years from now.


D2 -> D3 will be full of breaking changes anyway. Otherwise there is no
reason to add another major language version.



What is this D3 thing 
As far as I can tell, 'D3' was invented by newcomers to the forums.

Re: Const/Shared/Immutable anomalies in D that should be fixed

[Steven Schveighoffer]

On Thu, 03 May 2012 03:45:51 -0400, Chris Cain  wrote:


On Thursday, 3 May 2012 at 06:00:58 UTC, Mehrdad wrote:
I believe all of these static assertions (and some variants thereof)  
should pass, due to the semantics of const, immutable, and shared.


...

Do people agree?


 //static assert(is(Const == shared(Const))); // Doesn't pass


Right, there is a common misconception that const can be implicitly cast  
from shared, but it cannot.  It's orthogonal.


-Steve

Re: When is casting const() away actually necessary? (Used to be: Re: Why D const is annoying)

[Steven Schveighoffer]

On Wed, 02 May 2012 12:59:34 -0400, David Nadlinger   
wrote:



On Wednesday, 2 May 2012 at 16:52:33 UTC, Alex Rønne Petersen wrote:
shared? Almost always in any non-trivial application. shared is only  
useful if you're dealing with templatized functions that can actually  
handle it, which is not the case as often as one would like.


Additionally, shared is currently little more than a marker for non-TLS  
data.


No, it's very important that it is a type constructor.  For example, it  
makes weak-pure functions possible.


I think there is a large piece of shared missing/undefined, and that is,  
how do I mark something shared as "temporarily local".  I think Bartosz  
proposed something like "lent".


We essentially need the equivalent of const for shared.  Const unifies  
immutable and mutable, we need something to unify shared and thread-local.


The problem is, something like this needs to be combined with  
thread-locks.  I wonder if some kind of ARC would be useful for  
automatically unlocking the data.


-Steve

Re: Does D have too many features?

[Don Clugston]

On 28/04/12 20:47, Walter Bright wrote:

Andrei and I had a fun discussion last night about this question. The
idea was which features in D are redundant and/or do not add significant
value?

A couple already agreed upon ones are typedef and the cfloat, cdouble
and creal types.

What's your list?


Other ones which were agreed to a long time ago were:

* NCEG operators

* built-in .sort and .reverse

=

About the NCEG operators -- the reason they're redundant is that you 
practically always want to treat NaN separately.


I've tried _very_ hard to come up with uses for them, but without success.

The thing I've used the most is:
x !<>= x

which is a kind of built-in isNaN(x), but that can also be rewritten as:
x != x

Initially I though you'd do things like

real func(real x)
{
// x must be non-NaN and in the range -x.infinity .. N
  if (x !< N)
  return real.nan;

but even that isn't convincing, because if x is NaN you should be 
returning x, so that you preserve NaN payloads.


I think I have used these guys more than anyone else, but I still 
haven't found a single use case that stands up to scrutiny.

From Ada 2012

[bearophile]

Ada shares many purposes with D: correctness from the language 
design too, mostly imperative, native compilation, efficiency of 
the binary, closeness to the metal (even more, because not 
requiring a GC, it's probably usable in more situations), generic 
programming, OOP, strong static typing, and both languages share 
many small features (like array slicing syntax, and so on).


Coding in Ada is a bit boring, because you have to specify every 
small detail and to write a lot, but for certain programming 
tasks, like code that can't have too many bugs, it's maybe the 
best language. As Ada vendors say, if your life depends on a 
program, you often prefer that code to be written in good Ada 
instead of good C. Even if writing Ada is slower than writing C 
or C++, you save some time later debugging less. Today for 
certain tasks Haskell seems to produce reliable code, but it uses 
a GC and it's lazy, so it's quite less strict compared to Ada.


I've found another pack of slides about the Ada 2012 language:
http://www.slideshare.net/AdaCore/ada-2012

Come quotations and comments from/about the slides:

[page 3] >In High-Reliable Software, choice is usually being made 
between C C++ Java Ada<


Maybe someday D too will be among those.


[p.6] >Applying these skills to any programming language should 
be easy for any developer<


Good luck with programming in Haskell :-)


[p.7] >Is the language properly supported by tools?<

Right, some bugs are avoided thanks to the supporting tools too.


[p.8] >Can the language full development cycle 
(specification/code/verification)?<


I don't know, regarding D.


[p.15] >Put as much (formal) information as possible in the code<

This is quite important for a language that wants to enforce more 
correctness.



[p.17] >Values are checked at run-time (can be deactivated)<

This often saves the programmer ass.


[p.19] >Arrays can be indexed by any discrete types (integers, 
enumeration)<


This is quite handy for enums (and sometimes chars), and 
reliable. Currently in D if you define an array with enum index 
you get an associative array, that is wasteful in both memory and 
performance for most enums that have contiguous values (but I 
think maybe D implementations will be free to use a more 
efficient array here, because the interface of AAs is opaque).



[p.21]
Three parameter modes : in (input), out (output) and in-out 
(input/output)


procedure Do_Something
  (P1 : in Integer; --  P1 can’t be changed
   P2 : outInteger; --  No initial value on P2


In D P2 is initialized...


[p.21]

The compiler decides if it has to be passed by reference of copy

procedure Do_Something
  (P1 : in Huge_Structure) –-  Passed by reference if too big


D offers more low-level knowlege/control here, it doesn't decide 
to pass by value or reference, leaving the decision to the 
programmer, I prefer D here.
But in D code like this, where a large value is passed, I'd like 
the D compiler to give a warning (despite once in a while that's 
exactly what you want?):


alias int[1_000] TA;
void int(TA a) {}


[p.22]
Generalized contracts are available through pre and 
post-conditions


procedure P (V : in out Integer)
   with Pre  => V >= 10,
Post => V'Old /= V;


So there's the Old (prestate) too in the Ada2012 built-in 
contract programming.



[p.30]

* Pointers are typed, associated with accessibility checks
* Objects that can be pointed are explicitly identifed
* Pointers constraints can be specified
– Is null value expected?
– Is the pointer constant?
– Is the object pointed by the pointer constant?


Ada has severl kinds of pointers, according to how much freedom 
they have.



[p.36]

Ada 2012 detects "obvious" aliasing problems

function Change (X, Y : in out Integer) return Integer is
   begin
  X := X * 2;
  Y := Y * 4;

  return X + Y;
   end;

   One, Two : Integer := 1;

begin

   Two := Change (One, One);
   -- warning: writable actual for "X" overlaps with actual for 
"Y“


   Two := Change (One, Two) + Change (One, Two);
   --  warning: result may differ if evaluated after other 
actual in expression


Are such warnings/tests useful in D too?
D compiles this with no warnings/errors:

int change(ref int x, ref int y) {
x *= 2;
y *= 4;
return x + y;
}
void main() {
int one = 1, two;
two = change(one, one);
two = change(one, two) + change(one, two);
}


[p.42]

if C in 'a' | 'e' | 'i'
  | 'o' | 'u' | 'y' then


Sometimes Ada2012 is succint too.


[p.43]
Function implementation can be directly given at specification 
time if it represents only an "expression"


function Even (V : Integer) return Boolean
   is (V mod 2 = 0);


It's related to:
http://d.puremagic.com/issues/show_bug.cgi?id=7176

Bye,
bearophile

Re: Does D have too many features?

[Andrei Alexandrescu]

On 5/3/12 9:55 AM, Don Clugston wrote:

On 28/04/12 20:47, Walter Bright wrote:

Andrei and I had a fun discussion last night about this question. The
idea was which features in D are redundant and/or do not add significant
value?

A couple already agreed upon ones are typedef and the cfloat, cdouble
and creal types.

What's your list?


Other ones which were agreed to a long time ago were:

* NCEG operators

* built-in .sort and .reverse


Good ones. In fact I even discounted them from this discussion because 
I'd already considered them gone. Walter agreed that I don't mention 
them in TDPL, with the intent to have them peter out.


One good step right now would be to remove NCEG operators from the 
online documentation. Later on, we'll consider them an accept-invalid 
bug :o).



Andrei

Re: D3 is potentially damaging

[H. S. Teoh]

On Thu, May 03, 2012 at 10:22:16AM +0200, James Miller wrote:
[...]
> D3 would be fine, iff it was easy to port D2 across and easy to
> continue using D2 code. A big problem with Python2 -> Python3 is the
> fact that it is a nightmare to have both running side-by-side.
> 
> I don't really think that D3 is a good idea, it would probably be
> better to gradually deprecate code going forward and replace the
> broken syntax and non backwards-compatible code.
> 
> Another useful could be to have a pragma(version, 2) so the compiler
> compiles with version 2 rules, no porting needed, just a single line
> near the top.
[...]

+1 to the pragma. If there ever will be a D3, this will be indispensible
to not lose the majority of existing users.

OTOH, it will make the compiler much harder to maintain.


T

-- 
Once bitten, twice cry...

Re: An observation

[H. S. Teoh]

On Thu, May 03, 2012 at 12:07:44PM +0200, Tobias Pankrath wrote:
> >
> >Not that I'm advocating Mutt, but I do recommend taking the time to
> >learn to use a threading mail/news reader. It will help you keep up
> >with very high traffic mailing lists/forums, and not just the D
> >forums.  (D's forums are relatively tame, comparatively speaking.
> >I've been on mailing lists where traffic is measured in units of
> >hundreds per day. And I used to be subscribed to several of them.
> >Never had a problem keeping up.  Just delete tree whenever it's
> >tl;dr. :-))
> >
> 
> Does the D newsgroup have broken threading in mutt? In my client
> threading breaks often because some answers starts new thread etc.
> makes the hole thing useless.

To be honest, I don't know. I suspect there's some sort of
incompatibility (people tell me that my replies are always broken, but I
don't see it, and I do notice some people's replies being out of place).
It doesn't happen often enough to be troublesome, though. A subthread
may break into two or three, but you can still mass-delete them easily
if you're not interested in that particular topic.


T

-- 
It is the quality rather than the quantity that matters. -- Lucius Annaeus 
Seneca

Growing pains

[Andrei Alexandrescu]

Just letting you all know we're working on the frustrating and 
increasingly frequent "Load at xx.xx, try again later" errors when 
reading this forum through NNTP. They are caused by a significant growth 
spurt in newsgroup readership that occurred in recent times. We are 
working with our provider to fix these issues.


Thanks,

Andrei

Re: Does D have too many features?

[Don Clugston]

On 03/05/12 16:13, Andrei Alexandrescu wrote:

On 5/3/12 9:55 AM, Don Clugston wrote:

On 28/04/12 20:47, Walter Bright wrote:

Andrei and I had a fun discussion last night about this question. The
idea was which features in D are redundant and/or do not add significant
value?

A couple already agreed upon ones are typedef and the cfloat, cdouble
and creal types.

What's your list?


Other ones which were agreed to a long time ago were:

* NCEG operators

* built-in .sort and .reverse


Good ones. In fact I even discounted them from this discussion because
I'd already considered them gone. Walter agreed that I don't mention
them in TDPL, with the intent to have them peter out.

One good step right now would be to remove NCEG operators from the
online documentation. Later on, we'll consider them an accept-invalid
bug :o).


Well, they are also used in druntime, in core.stdc.math

BTW I *hate* that module, I don't know why it exists. Even worse, it 
seems to be growing -- people are adding more things to it.

Practically everything in there has a better implementation in std.math.

Pure memoization, and more

[bearophile]

Threads like "Why D const is annoying" show that there is desire 
for logical immutability, for pure memoization, etc. I'd like the 
memoization of a pure function to be pure still.


This is a closely related group of problems (including "pointer 
equality, external pointers, finalizers, and weak pointers") 
surely present in functional languages too, so (with a bit of 
help from a person of the "Lambda The Ultimate" blog) I have 
found two papers that show some ideas and solutions.


"Stretching the storage manager: weak pointers and stable names 
in Haskell" (1999), by Simon Peyton Jones, Simon Marlow, and 
Conal Elliot:

http://community.haskell.org/~simonmar/papers/weak.pdf
http://research.microsoft.com/apps/pubs/default.aspx?id=67497

"Observable sharing for functional circuit description" (1999), 
by Koen Claessen, David Sands (this looks less related, but the 
authors face the same class of problems):

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.4053

Probably there are other papers on this topic, with solutions 
that don't require breaking purity or immutability in user code.


Bye,
bearophile

Re: When is casting const() away actually necessary? (Used to be: Re: Why D const is annoying)

[David Nadlinger]

On Thursday, 3 May 2012 at 13:40:41 UTC, Steven Schveighoffer 
wrote:
On Wed, 02 May 2012 12:59:34 -0400, David Nadlinger 
 wrote:
Additionally, shared is currently little more than a marker 
for non-TLS data.


No, it's very important that it is a type constructor.  For 
example, it makes weak-pure functions possible.


I think there is a large piece of shared missing/undefined, and 
that is, how do I mark something shared as "temporarily local".

 I think Bartosz proposed something like "lent".

We essentially need the equivalent of const for shared.  Const 
unifies immutable and mutable, we need something to unify 
shared and thread-local.


The problem is, something like this needs to be combined with 
thread-locks.  I wonder if some kind of ARC would be useful for 
automatically unlocking the data.


Yes, it is important indeed, at least if we want the type system 
to give guarantees about multi-threaded code. I just meant that 
in the current state, it provides little more than a way to make 
sure that shared data isn't accidentally passed around/used in 
places where synchronization isn't properly handled, because none 
of the fancier related ideas have actually been implemented so 
far.


David

Re: Pure memoization, and more

[David Nadlinger]

On Thursday, 3 May 2012 at 15:50:36 UTC, bearophile wrote:
Threads like "Why D const is annoying" show that there is 
desire for logical immutability, for pure memoization, etc. I'd 
like the memoization of a pure function to be pure still.


If you are performing a »logically pure« operation which can't 
be proven to be so due to the limits of the type system, you can 
always just use a cast in the implementation.


David

Re: From Ada 2012

[Artur Skawina]

On 05/03/12 16:04, bearophile wrote:
> [p.19] >Arrays can be indexed by any discrete types (integers, enumeration)<
> 
> This is quite handy for enums (and sometimes chars), and reliable. Currently 
> in D if you define an array with enum index you get an associative array, 
> that is wasteful in both memory and performance for most enums that have 
> contiguous values (but I think maybe D implementations will be free to use a 
> more efficient array here, because the interface of AAs is opaque).

It's a reasonable default; D will let you choose how it's done.

   struct EA(T,I) {
  enum size_t FIRST = I.min, N = I.max - FIRST + 1;
  T[N] a;
  auto opIndex(I i) { return a[i-FIRST]; }
  auto opIndexAssign(T v, I i) { return a[i-FIRST] = v; }
  // etc for any other useful operator
   }

   enum E { one=10, two, three }

   EA!(int, E) a;
   a[E.three] = 42;
   assert(a[E.three]==42);
   assert(a.sizeof==int.sizeof*3);  

It doesn't get much more efficient than this; the compiler will take
care of the rest, both the type checking and optimizing it all away.

Maybe something like this should be in the std lib, but i'm not sure if
it's very useful in it's raw form, usually you'll want a custom version;
it would be more suited for a mixin-template library.

artur

Re: Pure memoization, and more

[bearophile]

David Nadlinger:

If you are performing a »logically pure« operation which 
can't be proven to be so due to the limits of the type system, 
you can always just use a cast in the implementation.


casts are dangerous, better to avoid them where possible. Those 
papers try to avoid unsafe casts in user code and libraries.


Bye,
bearophile

Re: Windows batch file to compile D code

[Manu]

Are you a visual studio user? Tried VisualD?
If not, tried Mono-D?

On 3 May 2012 15:31, Iain Staffell  wrote:

> Hi all.
>
> I have been trying (quite badly) to get started with D for a while.
>
> On my first attempt I gave up before even compiling Hello World, because
> it was too difficult to find out how to even compile a program in Windows.
>  (I know.. I said I was bad at this..)
>
> Second time around I tried harder, and wrote a Windows batch file to make
> compiling and running my code easier.  No messing around with PATH
> variables or things like that, too difficult.
>
> I have been playing around with this for a year or so now, and thought it
> might be useful to someone else trying to learn D.  So here is a batch file
> that will automatically compile and run your D code.
>
> If you're interested: save 
> http://wogone.com/code/D2.BAT.**TXTto your 
> computer, rename to D2.BAT, then run D2 from a command prompt for
> further instructions.
>
> Hope someone finds it useful, and not too buggy!  Any comments or
> improvements are more than welcome.
>

Re: How can D become adopted at my company?

[Manu]

On 3 May 2012 12:27, Don Clugston  wrote:

> On 30/04/12 01:03, Manu wrote:
>
>> On 30 April 2012 01:24, Tove > > wrote:
>>
>>On Sunday, 29 April 2012 at 22:13:22 UTC, Manu wrote:
>>
>>Is it technically possible to have a precise GC clean up all
>>unreferenced
>>memory in one big pass?
>>
>>
>>yes, but unless it's also moving/compacting... one would suffer
>>memory fragmentation... so I would imagine TempAlloc is a better fit?
>>
>>
>> In some cases I'm comfortable with that type of fragmentation (large
>> regularly sized resources), although that leads me to a gaping hole in
>> D's allocation system...
>>
>> 
>> There is no way to request aligned memory. I can't even specify an
>>
>> alignment on a user type and expect it to be aligned if I create one on
>> the stack, let alone the heap >_<
>> It seems I can request alignment for items within a struct, but I can't
>> align the struct its self. In addition, a struct doesn't inherit the
>> alignment of its aligned members, so the struct is allocated unaligned,
>> and the aligned member fails its promise anyway.
>>
>
> Bug 2278.
>

Why do you suggest alignment to only 8 bytes (not 16)? MOVAPS and friends
operate on 16 byte aligned data, and all non-x86 architectures are strictly
16byte aligned with no unaligned alternative possible.
I'd like to see that proposal extended to arbitrary power-of-2, and to
allow align(n) applied to structs/classes.

Re: An observation

[Regan Heath]

On Thu, 03 May 2012 15:31:25 +0100, H. S. Teoh   
wrote:



On Thu, May 03, 2012 at 12:07:44PM +0200, Tobias Pankrath wrote:

>
>Not that I'm advocating Mutt, but I do recommend taking the time to
>learn to use a threading mail/news reader. It will help you keep up
>with very high traffic mailing lists/forums, and not just the D
>forums.  (D's forums are relatively tame, comparatively speaking.
>I've been on mailing lists where traffic is measured in units of
>hundreds per day. And I used to be subscribed to several of them.
>Never had a problem keeping up.  Just delete tree whenever it's
>tl;dr. :-))
>

Does the D newsgroup have broken threading in mutt? In my client
threading breaks often because some answers starts new thread etc.
makes the hole thing useless.


To be honest, I don't know. I suspect there's some sort of
incompatibility (people tell me that my replies are always broken, but I
don't see it, and I do notice some people's replies being out of place).
It doesn't happen often enough to be troublesome, though. A subthread
may break into two or three, but you can still mass-delete them easily
if you're not interested in that particular topic.


I use the built-in reader for Opera Web Browser and it has correctly  
threaded your reply.  I see replies out of place a lot too, threads broken  
into pieces and occasionally a large-ish number of replies all listed at  
the top level.  I just bash 'm' to mark the thread read and move on.


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: Does D have too many features?

[Alex Rønne Petersen]

On 03-05-2012 17:13, Don Clugston wrote:

On 03/05/12 16:13, Andrei Alexandrescu wrote:

On 5/3/12 9:55 AM, Don Clugston wrote:

On 28/04/12 20:47, Walter Bright wrote:

Andrei and I had a fun discussion last night about this question. The
idea was which features in D are redundant and/or do not add
significant
value?

A couple already agreed upon ones are typedef and the cfloat, cdouble
and creal types.

What's your list?


Other ones which were agreed to a long time ago were:

* NCEG operators

* built-in .sort and .reverse


Good ones. In fact I even discounted them from this discussion because
I'd already considered them gone. Walter agreed that I don't mention
them in TDPL, with the intent to have them peter out.

One good step right now would be to remove NCEG operators from the
online documentation. Later on, we'll consider them an accept-invalid
bug :o).


Well, they are also used in druntime, in core.stdc.math

BTW I *hate* that module, I don't know why it exists. Even worse, it
seems to be growing -- people are adding more things to it.
Practically everything in there has a better implementation in std.math.


But not quite everything yet. When I tried to pure/nothrow/@safe-ify 
std.math[special], I eventually stumbled upon code that used core.stdc.math.


It would definitely be nice if we could completely kill any dependency 
on that module, so we can actually make proper use of 
pure/nothrow/@safe, etc.


--
- Alex

Re: From Ada 2012

[Kagamin]

On Thursday, 3 May 2012 at 14:04:41 UTC, bearophile wrote:

[p.21]
The compiler decides if it has to be passed by reference of 
copy


procedure Do_Something
 (P1 : in Huge_Structure) –-  Passed by reference if too big


D offers more low-level knowlege/control here, it doesn't 
decide to pass by value or reference, leaving the decision to 
the programmer, I prefer D here.
But in D code like this, where a large value is passed, I'd 
like the D compiler to give a warning (despite once in a while 
that's exactly what you want?):


alias int[1_000] TA;
void int(TA a) {}


I was surprised a little when compiler rejected `ref in`.

Re: From Ada 2012

[bearophile]

Currently in D if you define an array with enum index you get 
an associative array, that is wasteful in both memory and 
performance for most enums that have contiguous values (but I 
think maybe D implementations will be free to use a more 
efficient array here, because the interface of AAs is opaque).


And there is this small problem too:
http://d.puremagic.com/issues/show_bug.cgi?id=6974



Kagamin:


I was surprised a little when compiler rejected `ref in`.


But this compiles:

alias int[1_000] TA;
void foo(const ref TA a) {}
void main() {}

Bye,
bearophile

Class methods in D?

[Mehrdad]

In Windows, you need to register a "window class" before you can actually 
create an instance of it.


Mapping this idea to D (and most other languages, I admit) is hard. 
Microsoft's solution in C# is pretty ugly.


The problem is this:
You make a class like
class Window
{
   HWND handle;
   virtual @property string className()  // How the system identifies this 
subclass

   { /*some default code for lazily registering a class*/ }
   this() { this.handle = className(this.className, ...); }
}
which people are supposed to inherit from.

The trouble is that there is *no clean way* (that I can think of) to ensure 
this:

if (typeid(windowA) == typeid(windowB))
{ assert(windowA.className == windowB.className); }

This is necessary in order to make sure that the idea of a "class" in D is 
the same as the one that the system sees.


If className() was class method, this assumption would be trivial to ensure: 
subclasses could override it, and it would be the same for all instances of 
the class. It would map to OOP in D **VERY** cleanly.
Right now, though, it's a big pain to map this concept... and the lack of 
proper reflection isn't helping.
(Microsoft just decided to make it an instance property, but if you look at 
the code, you'll see it's infinitely ugly...)


Is there any chance that we can get (overridable) class methods in D?
If not, is there a good solution to this problem?
(At least, will it be possible to retrieve the static methods of a class 
with reflection?) 

Re: Class methods in D?

[Mehrdad]

   this() { this.handle = className(this.className, ...); }


whoops, typo.

That line should say:
this() { this.handle = CreateWindow(this.className, ...); }

Feature !request into std.algorithm

[bioinfornatics]

into std.algorithm they are countUntil that is a useful function buit
when you want the first index of many token is same sequence you need to
all many times countUntil and then loop many time in the same sequence.
This is a inefficiency way. i have wrote a function where loop at max
one time over the sequence. 
for go to algorithm a template replace char[] by Range i think

---
@safe nothrow pure
sizediff_t[char[]] searchIndex( in char[] sequence, in char[][]
token...)
in{
  assert(sequence !is null, "Error given sequence is null");
}
body{
  bool   isComputing = true;
  size_t index   = 0;
  size_t flag= 0;
  sizediff_t[char[]] result;

  foreach( tok; token)
result[tok] = -1;

  while(isComputing){
if( index >= sequence.length )
  isComputing = false;
else if( flag == token.length )
  isComputing = false;
else{
  foreach( tok; token){
if( sequence.length - index >= tok.length ){
  const(char)[] currentToken = (tok.length > 1) ?
sequence[index .. index + tok.length] : [sequence[index]];
  if( currentToken in result && result[currentToken] == -1 ){
result[currentToken] = index;
flag++;
  }
}
  }
  index++;
}
  }
  return result;
}

Re: From Ada 2012

[Steven Schveighoffer]

On Thu, 03 May 2012 13:03:34 -0400, Kagamin  wrote:


On Thursday, 3 May 2012 at 14:04:41 UTC, bearophile wrote:

[p.21]

The compiler decides if it has to be passed by reference of copy
 procedure Do_Something
 (P1 : in Huge_Structure) –-  Passed by reference if too big


D offers more low-level knowlege/control here, it doesn't decide to  
pass by value or reference, leaving the decision to the programmer, I  
prefer D here.
But in D code like this, where a large value is passed, I'd like the D  
compiler to give a warning (despite once in a while that's exactly what  
you want?):


alias int[1_000] TA;
void int(TA a) {}


I was surprised a little when compiler rejected `ref in`.


in is synonymous for "const scope".

Doing "const scope ref" yields:

"scope cannot be ref or out"

which makes sense.  Just use const instead.

-Steve

Re: Class methods in D?

[Steven Schveighoffer]

On Thu, 03 May 2012 13:21:55 -0400, Mehrdad  wrote:

In Windows, you need to register a "window class" before you can  
actually create an instance of it.


Mapping this idea to D (and most other languages, I admit) is hard.  
Microsoft's solution in C# is pretty ugly.


The problem is this:
You make a class like
class Window
{
HWND handle;
virtual @property string className()  // How the system identifies  
this subclass

{ /*some default code for lazily registering a class*/ }
this() { this.handle = className(this.className, ...); }
}
which people are supposed to inherit from.

The trouble is that there is *no clean way* (that I can think of) to  
ensure this:

if (typeid(windowA) == typeid(windowB))
{ assert(windowA.className == windowB.className); }

This is necessary in order to make sure that the idea of a "class" in D  
is the same as the one that the system sees.


If className() was class method, this assumption would be trivial to  
ensure: subclasses could override it, and it would be the same for all  
instances of the class. It would map to OOP in D **VERY** cleanly.
Right now, though, it's a big pain to map this concept... and the lack  
of proper reflection isn't helping.
(Microsoft just decided to make it an instance property, but if you look  
at the code, you'll see it's infinitely ugly...)


Is there any chance that we can get (overridable) class methods in D?
If not, is there a good solution to this problem?
(At least, will it be possible to retrieve the static methods of a class  
with reflection?)


This works:

import std.stdio;

class A
{
  string name;
  this() {this.name = typeid(this).name;}
}

class B : A {}

void main()
{
   A b = new B;
   A a = new A;
   writefln("A: %s, B: %s", a.name, b.name);
}

outputs:

A: testclassname.A, B: testclassname.B

Do what you want with that name, not sure if the window class can have  
dots in it... (I haven't done much low-level GUI work on windows).


Why does this work?  Because typeid(obj) gets the TypeInfo based on the  
object's *derived* type, not it's static type.  Since the typeinfo is  
properly set before the ctor is called, this means you get the correct  
type.  Also, note if there is anything you need via the TypeInfo, it's  
accessible.  Given the recent additions to the compiler and the RTInfo  
template, you should be able to generate everything you need.


-Steve

Re: Class methods in D?

[Mehrdad]

On Thursday, 3 May 2012 at 17:45:20 UTC, Steven Schveighoffer 
wrote:

This works:

import std.stdio;

class A
{
  string name;
  this() {this.name = typeid(this).name;}
}

class B : A {}

void main()
{
   A b = new B;
   A a = new A;
   writefln("A: %s, B: %s", a.name, b.name);
}

outputs:

A: testclassname.A, B: testclassname.B

-Steve


Oh, but that's only the name!

The trouble is that window classes have a lot of attributes -- 
styles, background brushes, etc. -- that are all shared across 
instances.


There is currently no way (that I know of) to allow a subclass to 
define its own attributes, *without* also giving it a chance to 
define them per-instance instead of per-class.

Re: Const/Shared/Immutable anomalies in D that should be fixed

[kenji hara]

It is bug 7038 and has been fixed in 2.059.
http://d.puremagic.com/issues/show_bug.cgi?id=7038

Kenji Hara
2012/05/03 15:04 "Mehrdad" :

> I believe all of these static assertions (and some variants thereof)
> should pass, due to the semantics of const, immutable, and shared.
>
> immutable struct Immutable { }
> const struct Const { }
> shared struct Shared { }
> static assert(is(Immutable == immutable(Immutable)));
> static assert(is(Immutable == const(Immutable)));
> static assert(is(Immutable == shared(Immutable)));
> static assert(is(Const == const(Const)));
> static assert(is(Const == shared(Const)));
> static assert(is(Shared == shared(Shared)));
>
>
> Do people agree?
>
> Also, what exactly is the difference between declaring a struct as
> immutable or as const? Aren't they unmodifiable either way?
>

Re: Class methods in D?

[Steven Schveighoffer]

On Thu, 03 May 2012 13:48:24 -0400, Mehrdad  wrote:


On Thursday, 3 May 2012 at 17:45:20 UTC, Steven Schveighoffer wrote:

This works:

import std.stdio;

class A
{
  string name;
  this() {this.name = typeid(this).name;}
}

class B : A {}

void main()
{
   A b = new B;
   A a = new A;
   writefln("A: %s, B: %s", a.name, b.name);
}

outputs:

A: testclassname.A, B: testclassname.B

-Steve


Oh, but that's only the name!

The trouble is that window classes have a lot of attributes -- styles,  
background brushes, etc. -- that are all shared across instances.


There is currently no way (that I know of) to allow a subclass to define  
its own attributes, *without* also giving it a chance to define them  
per-instance instead of per-class.


There's the RTInfo method I told you about (recently added) if you want to  
stick the information directly into TypeInfo at compile time.


There's also static ctors.  Just add a hashtable based on the class name,  
and use typeid(this).name as the initial key.  You have to handle all the  
inheritance of properties yourself, but that shouldn't be too difficult.


-Steve

Re: Class methods in D?

[Mehrdad]

There's the RTInfo method I told you about (recently added) if 
you want to stick the information directly into TypeInfo at 
compile time.


There's also static ctors.  Just add a hashtable based on the 
class name, and use typeid(this).name as the initial key.  You 
have to handle all the inheritance of properties yourself, but 
that shouldn't be too difficult.


-Steve


Ooh... how do I get RTInfo? It's not in druntime/phobos

scope ref const(T) --> error?!

[Mehrdad]

What's wrong with passing a struct as scope ref const?

I want to avoid copying the struct, and its information is only 
read inside the function...

Re: From Ada 2012

[Alex Rønne Petersen]

On 03-05-2012 19:36, Steven Schveighoffer wrote:

On Thu, 03 May 2012 13:03:34 -0400, Kagamin  wrote:


On Thursday, 3 May 2012 at 14:04:41 UTC, bearophile wrote:

[p.21]

The compiler decides if it has to be passed by reference of copy
procedure Do_Something
(P1 : in Huge_Structure) –- Passed by reference if too big


D offers more low-level knowlege/control here, it doesn't decide to
pass by value or reference, leaving the decision to the programmer, I
prefer D here.
But in D code like this, where a large value is passed, I'd like the
D compiler to give a warning (despite once in a while that's exactly
what you want?):

alias int[1_000] TA;
void int(TA a) {}


I was surprised a little when compiler rejected `ref in`.


in is synonymous for "const scope".

Doing "const scope ref" yields:

"scope cannot be ref or out"

which makes sense. Just use const instead.

-Steve


Doesn't make sense to me. It seems perfectly normal to do something like 
this:


void foo(ref in int i)
{
i = 42; // we're setting i indirectly, and not leaking it
}

int i;
foo(i);

--
- Alex

Re: Class methods in D?

[Simon]

On 03/05/2012 18:21, Mehrdad wrote:

In Windows, you need to register a "window class" before you can
actually create an instance of it.


If you are mucking about on 'doze you might find my dubious port of the 
ATL window classes relevant:


http://www.sstk.co.uk/atlWinD.php

That does all that tedious registering of windows classes etc.
I used a static class member IIRC.

I've ripped this off of MS so use at your own risk. ;)

--
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

Re: Class methods in D?

[Mehrdad]

On Thursday, 3 May 2012 at 18:32:18 UTC, Simon wrote:

On 03/05/2012 18:21, Mehrdad wrote:
In Windows, you need to register a "window class" before you 
can

actually create an instance of it.


If you are mucking about on 'doze you might find my dubious 
port of the ATL window classes relevant:


http://www.sstk.co.uk/atlWinD.php

That does all that tedious registering of windows classes etc.
I used a static class member IIRC.

I've ripped this off of MS so use at your own risk. ;)


lol. thanks.

virtual method pointer

[Gor Gyolchanyan]

I need to get a pointer to a virtual method, which is in turn a
function pointer, being set by virtual method binding.
Can anyone, please, tell me how to get it? Taking the delegate of the
method won't do, because I need it to behave exactly as a virtual
method call, except I pass the "this" explicitly.
I need this in an event handling mechanism I'm making. You derive from
the Sink class, passing your static type to the constructor, which
scans your virtual methods, that conform to specific requirements and
extracts them into an array, which later uses to dispatch the incoming
events.
It will feel much like a run-time virtual template method.

-- 
Bye,
Gor Gyolchanyan.

Re: From Ada 2012

[Alex Rønne Petersen]

On 03-05-2012 20:29, Alex Rønne Petersen wrote:

On 03-05-2012 19:36, Steven Schveighoffer wrote:

On Thu, 03 May 2012 13:03:34 -0400, Kagamin  wrote:


On Thursday, 3 May 2012 at 14:04:41 UTC, bearophile wrote:

[p.21]

The compiler decides if it has to be passed by reference of copy
procedure Do_Something
(P1 : in Huge_Structure) –- Passed by reference if too big


D offers more low-level knowlege/control here, it doesn't decide to
pass by value or reference, leaving the decision to the programmer, I
prefer D here.
But in D code like this, where a large value is passed, I'd like the
D compiler to give a warning (despite once in a while that's exactly
what you want?):

alias int[1_000] TA;
void int(TA a) {}


I was surprised a little when compiler rejected `ref in`.


in is synonymous for "const scope".

Doing "const scope ref" yields:

"scope cannot be ref or out"

which makes sense. Just use const instead.

-Steve


Doesn't make sense to me. It seems perfectly normal to do something like
this:

void foo(ref in int i)
{
i = 42; // we're setting i indirectly, and not leaking it
}

int i;
foo(i);



On second thought, the 'const' in the 'in' would probably make this 
nonsensical. Still, passing structs by ref is a case where 'ref in' 
makes sense (e.g. matrices).


--
- Alex

Re: Windows batch file to compile D code

[simendsjo]

On Thu, 03 May 2012 15:29:07 +0200, David  wrote:


Am 03.05.2012 14:31, schrieb Iain Staffell:

Hi all.

I have been trying (quite badly) to get started with D for a while.

On my first attempt I gave up before even compiling Hello World, because
it was too difficult to find out how to even compile a program in
Windows. (I know.. I said I was bad at this..)

Second time around I tried harder, and wrote a Windows batch file to
make compiling and running my code easier. No messing around with PATH
variables or things like that, too difficult.

I have been playing around with this for a year or so now, and thought
it might be useful to someone else trying to learn D. So here is a batch
file that will automatically compile and run your D code.

If you're interested: save http://wogone.com/code/D2.BAT.TXT to your
computer, rename to D2.BAT, then run D2 from a command prompt for
further instructions.

Hope someone finds it useful, and not too buggy! Any comments or
improvements are more than welcome.

rdmd? http://dlang.org/rdmd.html


And dvm: https://github.com/jacob-carlborg/dvm

Re: virtual method pointer

[Alex Rønne Petersen]

On 03-05-2012 20:46, Gor Gyolchanyan wrote:

I need to get a pointer to a virtual method, which is in turn a
function pointer, being set by virtual method binding.
Can anyone, please, tell me how to get it? Taking the delegate of the
method won't do, because I need it to behave exactly as a virtual
method call, except I pass the "this" explicitly.
I need this in an event handling mechanism I'm making. You derive from
the Sink class, passing your static type to the constructor, which
scans your virtual methods, that conform to specific requirements and
extracts them into an array, which later uses to dispatch the incoming
events.
It will feel much like a run-time virtual template method.



import std.stdio;

class A
{
void foo()
{
writeln("foo called");
}
}

void main()
{
auto a = new A();
auto fn = &a.foo;
auto ptr = fn.funcptr;
(cast(void function(A))ptr)(a);
}

Prints "foo called".

--
- Alex

Re: virtual method pointer

[Gor Gyolchanyan]

class B: A
{
void foo()
{
writeln("B.foo called");
}
}

void main()
{
   auto a = new A();
   auto fn = &a.foo;
   auto ptr = fn.funcptr;
   auto b = new B();
   (cast(void function(A))ptr)(b);
}

will this work?

On Thu, May 3, 2012 at 10:54 PM, Alex Rønne Petersen
 wrote:
> On 03-05-2012 20:46, Gor Gyolchanyan wrote:
>>
>> I need to get a pointer to a virtual method, which is in turn a
>> function pointer, being set by virtual method binding.
>> Can anyone, please, tell me how to get it? Taking the delegate of the
>> method won't do, because I need it to behave exactly as a virtual
>> method call, except I pass the "this" explicitly.
>> I need this in an event handling mechanism I'm making. You derive from
>> the Sink class, passing your static type to the constructor, which
>> scans your virtual methods, that conform to specific requirements and
>> extracts them into an array, which later uses to dispatch the incoming
>> events.
>> It will feel much like a run-time virtual template method.
>>
>
> import std.stdio;
>
> class A
> {
>    void foo()
>    {
>        writeln("foo called");
>    }
> }
>
> void main()
> {
>    auto a = new A();
>    auto fn = &a.foo;
>    auto ptr = fn.funcptr;
>    (cast(void function(A))ptr)(a);
> }
>
> Prints "foo called".
>
> --
> - Alex



-- 
Bye,
Gor Gyolchanyan.

Re: Does D have too many features?

[Sean Kelly]

On May 3, 2012, at 8:13 AM, Don Clugston wrote:

> On 03/05/12 16:13, Andrei Alexandrescu wrote:
>> 
>> 
>> Good ones. In fact I even discounted them from this discussion because
>> I'd already considered them gone. Walter agreed that I don't mention
>> them in TDPL, with the intent to have them peter out.
>> 
>> One good step right now would be to remove NCEG operators from the
>> online documentation. Later on, we'll consider them an accept-invalid
>> bug :o).
> 
> Well, they are also used in druntime, in core.stdc.math
> 
> BTW I *hate* that module, I don't know why it exists. Even worse, it seems to 
> be growing -- people are adding more things to it.
> Practically everything in there has a better implementation in std.math.

core.stdc.math corresponds to C99's math.h and is there as a part of the 
standard C interface.  It should only contain the required C99 prototypes, and 
in some cases functions if the C implementation is a macro.  If there is 
anything nonstandard in there, I'm not aware of it.

Re: Does D have too many features?

[Sean Kelly]

On May 3, 2012, at 9:58 AM, Alex Rønne Petersen wrote:

> On 03-05-2012 17:13, Don Clugston wrote:
>> 
>> 
>> Well, they are also used in druntime, in core.stdc.math
>> 
>> BTW I *hate* that module, I don't know why it exists. Even worse, it
>> seems to be growing -- people are adding more things to it.
>> Practically everything in there has a better implementation in std.math.
> 
> But not quite everything yet. When I tried to pure/nothrow/@safe-ify 
> std.math[special], I eventually stumbled upon code that used core.stdc.math.
> 
> It would definitely be nice if we could completely kill any dependency on 
> that module, so we can actually make proper use of pure/nothrow/@safe, etc.

I've always thought use of core.stdc as an indicator for things that should be 
added to Phobos.  Really, core.stdc should only be used by apps ported from C 
to D, not by apps written from scratch in D.

Re: virtual method pointer

[Mehrdad]

On Thursday, 3 May 2012 at 18:47:11 UTC, Gor Gyolchanyan wrote:

I need to get a pointer to a virtual method, which is in turn a
function pointer, being set by virtual method binding.
Can anyone, please, tell me how to get it? Taking the delegate 
of the
method won't do, because I need it to behave exactly as a 
virtual

method call, except I pass the "this" explicitly.
I need this in an event handling mechanism I'm making. You 
derive from
the Sink class, passing your static type to the constructor, 
which
scans your virtual methods, that conform to specific 
requirements and
extracts them into an array, which later uses to dispatch the 
incoming

events.
It will feel much like a run-time virtual template method.


Are you asking for the same thing I was asking for?
http://forum.dlang.org/thread/jn9ops$13bs$1...@digitalmars.com

Re: virtual method pointer

[Timon Gehr]

On 05/03/2012 09:01 PM, Gor Gyolchanyan wrote:

class B: A
{
 void foo()
 {
 writeln("B.foo called");
 }
}

void main()
{
auto a = new A();
auto fn =&a.foo;
auto ptr = fn.funcptr;
auto b = new B();
(cast(void function(A))ptr)(b);
}

will this work?



It should work (at least) with the D calling convention, yes.

A somewhat more portable way would probably be:

auto fn = &a.foo;
fn.ptr = cast(void*)b;
fn();

Re: virtual method pointer

[Gor Gyolchanyan]

No, because I'm not supposed to get delegates in the first place. What
I want is to have a pointer to a pointer to a function, so I can make
a true virtual call.

On Thu, May 3, 2012 at 11:09 PM, Mehrdad  wrote:
> On Thursday, 3 May 2012 at 18:47:11 UTC, Gor Gyolchanyan wrote:
>>
>> I need to get a pointer to a virtual method, which is in turn a
>> function pointer, being set by virtual method binding.
>> Can anyone, please, tell me how to get it? Taking the delegate of the
>> method won't do, because I need it to behave exactly as a virtual
>> method call, except I pass the "this" explicitly.
>> I need this in an event handling mechanism I'm making. You derive from
>> the Sink class, passing your static type to the constructor, which
>> scans your virtual methods, that conform to specific requirements and
>> extracts them into an array, which later uses to dispatch the incoming
>> events.
>> It will feel much like a run-time virtual template method.
>
>
> Are you asking for the same thing I was asking for?
> http://forum.dlang.org/thread/jn9ops$13bs$1...@digitalmars.com



-- 
Bye,
Gor Gyolchanyan.

Re: virtual method pointer

[Gor Gyolchanyan]

So, you're saying, that the foo function actually takes the *this,
which we ass manually, extracts the real foo method and calls it?
AFAIK, that shouldn't be the case. The delegate extracts the A's foo
and call to the delegate should be a direct call to A.foo, not a
virtual call.

On Thu, May 3, 2012 at 11:11 PM, Timon Gehr  wrote:
> On 05/03/2012 09:01 PM, Gor Gyolchanyan wrote:
>>
>> class B: A
>> {
>>     void foo()
>>     {
>>         writeln("B.foo called");
>>
>>     }
>> }
>>
>> void main()
>> {
>>    auto a = new A();
>>    auto fn =&a.foo;
>>    auto ptr = fn.funcptr;
>>    auto b = new B();
>>    (cast(void function(A))ptr)(b);
>> }
>>
>> will this work?
>>
>
> It should work (at least) with the D calling convention, yes.
>
> A somewhat more portable way would probably be:
>
> auto fn = &a.foo;
> fn.ptr = cast(void*)b;
> fn();



-- 
Bye,
Gor Gyolchanyan.

Re: Class methods in D?

[Steven Schveighoffer]

On Thu, 03 May 2012 14:05:26 -0400, Mehrdad  wrote:

There's the RTInfo method I told you about (recently added) if you want  
to stick the information directly into TypeInfo at compile time.


There's also static ctors.  Just add a hashtable based on the class  
name, and use typeid(this).name as the initial key.  You have to handle  
all the inheritance of properties yourself, but that shouldn't be too  
difficult.


-Steve


Ooh... how do I get RTInfo? It's not in druntime/phobos


https://github.com/D-Programming-Language/druntime/blob/master/import/object.di#L622

Need the github versions of dmd/druntime/phobos.

Basically how it works is the compiler evaluates RTInfo!T where T is the  
type for which TypeInfo is being generated, and places the result into a  
location that is returned by TypeInfo.rtInfo property.  This all happens  
at compile-time, so it effectively gives you a hook to store runtime type  
information into the TypeInfo.


As far as I know, there's not official documentation on it, it's a pretty  
beta feature.  But I think it will open a door to actual runtime type  
information that we never had before.


One limitation is, it has to be inside the runtime, and specifically in  
object.di.  However, we may be able to effectively generate class/struct  
specific runtime type information.  For example:


struct RTTI
{
  // druntime-specified properties
  ...
  // type-specific properties
  void *typeSpecificProperties;
}

template RTInfo_Instance(T)
{
   static if(is(typeof({void *x = T.__rtInfo();}))
 immutable RTTI RTInfo_Instance = RTTI(..., T.__rtInfo());
   else
 immutable RTTI RTInfo_Instance = RTTI(..., null);
}

template RTInfo(T)
{
   immutable void * RTInfo = &RTInfo_Instance!T;
}

I have no idea if this works :)  But I'm *positive* someone with better  
template skills than me can make something like this work.


-Steve

Re: virtual method pointer

[Timon Gehr]

On 05/03/2012 09:18 PM, Gor Gyolchanyan wrote:

So, you're saying, that the foo function actually takes the *this,
which we ass manually, extracts the real foo method and calls it?
AFAIK, that shouldn't be the case. The delegate extracts the A's foo
and call to the delegate should be a direct call to A.foo, not a
virtual call.



I just gave an alternative to Alex' solution, but it seems both do not 
actually do what you are after.


Is this good enough?

auto fn = function(A a){return a.foo();}

fn(a);
fn(b);

Re: Class methods in D?

[Mehrdad]

Oo ok I'll take a look at it, thanks.

Re: virtual method pointer

[Steven Schveighoffer]

On Thu, 03 May 2012 14:46:58 -0400, Gor Gyolchanyan  
 wrote:



I need to get a pointer to a virtual method, which is in turn a
function pointer, being set by virtual method binding.


Not exactly.  There is a workaround:

http://www.drdobbs.com/blogs/cpp/231600610

-Steve

Re: From Ada 2012

[Paulo Pinto]

Am 03.05.2012 16:04, schrieb bearophile:

Ada shares many purposes with D: correctness from the language design
too, mostly imperative, native compilation, efficiency of the binary,
closeness to the metal (even more, because not requiring a GC, it's
probably usable in more situations), generic programming, OOP, strong
static typing, and both languages share many small features (like array
slicing syntax, and so on).

Coding in Ada is a bit boring, because you have to specify every small
detail and to write a lot, but for certain programming tasks, like code
that can't have too many bugs, it's maybe the best language. As Ada
vendors say, if your life depends on a program, you often prefer that
code to be written in good Ada instead of good C. Even if writing Ada is
slower than writing C or C++, you save some time later debugging less.
Today for certain tasks Haskell seems to produce reliable code, but it
uses a GC and it's lazy, so it's quite less strict compared to Ada.


I am quite found of Ada, even if it means writting a bit more than C or 
C++, IDEs can help here. When coding in Java or .NET, the IDE writes 
most of the stuff already for me.


The company developing the open source Ada compiler GNAT, had the main
talk in this years FOSDEM.

Ada still suffers from the expensive compilers it had on the early 
years, but thanks to the increase in security concern in software, 
actually it seems to be picking up users in Europe, for projects where 
human lifes are at risk.


But D would, of course, be an easier upgrade path for C or C++ developers.

--
Paulo

Re: scope ref const(T) --> error?!

[Manu]

You're looking for 'in ref T'? I was also trying to do this today funnily
enough, and it seems a shame this doesn't work. Is this a bug, or is it
intended that it's not supported?

On 3 May 2012 21:28, Mehrdad  wrote:

> What's wrong with passing a struct as scope ref const?
>
> I want to avoid copying the struct, and its information is only read
> inside the function...
>

Re: Does D have too many features?

[Don]

On 03.05.2012 21:08, Sean Kelly wrote:

On May 3, 2012, at 8:13 AM, Don Clugston wrote:


On 03/05/12 16:13, Andrei Alexandrescu wrote:



Good ones. In fact I even discounted them from this discussion because
I'd already considered them gone. Walter agreed that I don't mention
them in TDPL, with the intent to have them peter out.

One good step right now would be to remove NCEG operators from the
online documentation. Later on, we'll consider them an accept-invalid
bug :o).


Well, they are also used in druntime, in core.stdc.math

BTW I *hate* that module, I don't know why it exists. Even worse, it seems to 
be growing -- people are adding more things to it.
Practically everything in there has a better implementation in std.math.


core.stdc.math corresponds to C99's math.h and is there as a part of the 
standard C interface.  It should only contain the required C99 prototypes, and 
in some cases functions if the C implementation is a macro.  If there is 
anything nonstandard in there, I'm not aware of it.


Yes, but why do we have it? We're not C.

Some of the std C functions aren't implemented correctly (especially the 
FreeBSD long double functions, which are completely wrong). And that 
shouldn't be D's problem. Even when they are, they're not pure nothrow, 
and sometimes they have really silly names (I'm looking at you, tgamma() )


Quite absurdly, the DMC gamma function is a port from the D version. Why 
include it twice??

Re: Growing pains

[SomeDude]

On Thursday, 3 May 2012 at 14:50:09 UTC, Andrei Alexandrescu 
wrote:
Just letting you all know we're working on the frustrating and 
increasingly frequent "Load at xx.xx, try again later" errors 
when reading this forum through NNTP. They are caused by a 
significant growth spurt in newsgroup readership that occurred 
in recent times. We are working with our provider to fix these 
issues.


Thanks,

Andrei


Ah cool. That was annoying enough, but the worst offenders were 
the errors when posting from the web interface.

Re: virtual method pointer

[Gor Gyolchanyan]

That workaround is pretty obvious, but I can't afford to make an extra
call every time. This event system is supposed to be ultra-fast. Isn't
there a way to get to the vtable etry itself?

On Thu, May 3, 2012 at 11:26 PM, Steven Schveighoffer
 wrote:
> On Thu, 03 May 2012 14:46:58 -0400, Gor Gyolchanyan
>  wrote:
>
>> I need to get a pointer to a virtual method, which is in turn a
>> function pointer, being set by virtual method binding.
>
>
> Not exactly.  There is a workaround:
>
> http://www.drdobbs.com/blogs/cpp/231600610
>
> -Steve



-- 
Bye,
Gor Gyolchanyan.

Re: virtual method pointer

[Gor Gyolchanyan]

No, I intend to call these methods very frequently and I can't afford
any performance loss.

What I expect to have is something like a virtual table entry. I tied
looking at the virtual tables and searching for the method delegate's
.funcptr in the vtable, but didn't find it.

Having that vtable entry would allow me to

On Thu, May 3, 2012 at 11:23 PM, Timon Gehr  wrote:
> On 05/03/2012 09:18 PM, Gor Gyolchanyan wrote:
>>
>> So, you're saying, that the foo function actually takes the *this,
>> which we ass manually, extracts the real foo method and calls it?
>> AFAIK, that shouldn't be the case. The delegate extracts the A's foo
>> and call to the delegate should be a direct call to A.foo, not a
>> virtual call.
>>
>
> I just gave an alternative to Alex' solution, but it seems both do not
> actually do what you are after.
>
> Is this good enough?
>
> auto fn = function(A a){return a.foo();}
>
> fn(a);
> fn(b);



-- 
Bye,
Gor Gyolchanyan.

Re: Does D have too many features?

[Jonathan M Davis]

On Thursday, May 03, 2012 15:30:40 Don Clugston wrote:
> What is this D3 thing 
> As far as I can tell, 'D3' was invented by newcomers to the forums.

I think that what it comes down to is that there are a variety of people who 
want features added or changed in D which are either not going to happen 
anytime soon or will never happen in D2 (especially if they're major breaking 
changes). So, they figure/hope that we'll have a new revision of the language 
where we'll be able to make breaking changes and then maybe the changes that 
they want will make it in then. After all, particularly from the perspective 
of a newbie, we already had D2 which changed a bunch of stuff from D1, why 
wouldn't we have D3 later on? And for folks who really want to see changes 
that aren't going to happen, the idea that we're going to have another major 
revision of the language which might make the changes that they want sounds 
really appealing.

I think that Walter and Andrei have made it fairly clear when they've said 
anything on the subject that there is no intention to make any kind of D3 
anytime soon and that if we do, it'll be years from now after D2 is mature and 
well-established, and it actually makes sense to do a new major revision. But 
I do think that you're right in that the very idea of a D3 was created by 
folks in the newsgroup. Walter and the other developers have been focusing on 
stabilizing D2 as _the_ version of the language, not finishing it up so that 
they can move onto D3. And the misconceptions about D1 that you've pointed out 
in the past probably just help contribute to the idea that we'll have a D3 at 
some point. Maybe we will, maybe we won't, but there's no point in worrying 
about it for years yet.

- Jonathan M Davis

Re: Does D have too many features?

[Sean Kelly]

On May 3, 2012, at 1:11 PM, Don wrote:

> On 03.05.2012 21:08, Sean Kelly wrote:
>> On May 3, 2012, at 8:13 AM, Don Clugston wrote:
>> 
>>> On 03/05/12 16:13, Andrei Alexandrescu wrote:
 
 
 Good ones. In fact I even discounted them from this discussion because
 I'd already considered them gone. Walter agreed that I don't mention
 them in TDPL, with the intent to have them peter out.
 
 One good step right now would be to remove NCEG operators from the
 online documentation. Later on, we'll consider them an accept-invalid
 bug :o).
>>> 
>>> Well, they are also used in druntime, in core.stdc.math
>>> 
>>> BTW I *hate* that module, I don't know why it exists. Even worse, it seems 
>>> to be growing -- people are adding more things to it.
>>> Practically everything in there has a better implementation in std.math.
>> 
>> core.stdc.math corresponds to C99's math.h and is there as a part of the 
>> standard C interface.  It should only contain the required C99 prototypes, 
>> and in some cases functions if the C implementation is a macro.  If there is 
>> anything nonstandard in there, I'm not aware of it.
> 
> Yes, but why do we have it? We're not C.

Mostly because it was handy to fall back on the C API before Phobos was so well 
fleshed-out.  Today, I think it mostly exists to ease porting of C apps.

Re: Growing pains

[deadalnix]

Le 03/05/2012 16:50, Andrei Alexandrescu a écrit :

Just letting you all know we're working on the frustrating and
increasingly frequent "Load at xx.xx, try again later" errors when
reading this forum through NNTP. They are caused by a significant growth
spurt in newsgroup readership that occurred in recent times. We are
working with our provider to fix these issues.

Thanks,

Andrei


I love you :D

It was so anoying when posting a message and *pof* « error your message 
is lost ».

Re: virtual method pointer

[deadalnix]

Le 03/05/2012 22:22, Gor Gyolchanyan a écrit :

That workaround is pretty obvious, but I can't afford to make an extra
call every time. This event system is supposed to be ultra-fast. Isn't
there a way to get to the vtable etry itself?


Well :
1/ Such a trivial thing is surely inlined by any compiler with 
optimizations on.

2/ You can afford a virtual dispatch, but can't afford a function call ?

I do think you are in case of premature optimizations here.

Re: Growing pains

[Ali Çehreli]

On 05/03/2012 01:52 PM, deadalnix wrote:

Le 03/05/2012 16:50, Andrei Alexandrescu a écrit :

Just letting you all know we're working on the frustrating and
increasingly frequent "Load at xx.xx, try again later" errors when
reading this forum through NNTP. They are caused by a significant growth
spurt in newsgroup readership that occurred in recent times. We are
working with our provider to fix these issues.

Thanks,

Andrei


I love you :D

It was so anoying when posting a message and *pof* « error your message
is lost ».


I've learned years ago to never trust a web page or a browser. I always 
type inside the Emacs *scratch* buffer and then copy and paste from 
there to the browser window. (I did it again! :) Actually no, this is a 
Thunderbird window, but still...)


Ali

Re: virtual method pointer

[Gor Gyolchanyan]

Good point. That raises the question: How should I make the fastest
possible dynamic dispatch of this kind?

On Fri, May 4, 2012 at 12:57 AM, deadalnix  wrote:
> Le 03/05/2012 22:22, Gor Gyolchanyan a écrit :
>
>> That workaround is pretty obvious, but I can't afford to make an extra
>> call every time. This event system is supposed to be ultra-fast. Isn't
>> there a way to get to the vtable etry itself?
>
>
> Well :
> 1/ Such a trivial thing is surely inlined by any compiler with optimizations
> on.
> 2/ You can afford a virtual dispatch, but can't afford a function call ?
>
> I do think you are in case of premature optimizations here.



-- 
Bye,
Gor Gyolchanyan.

Re: virtual method pointer

[Steven Schveighoffer]

On Thu, 03 May 2012 16:22:56 -0400, Gor Gyolchanyan  
 wrote:



That workaround is pretty obvious, but I can't afford to make an extra
call every time. This event system is supposed to be ultra-fast. Isn't
there a way to get to the vtable etry itself?


Well, you can use the ABI to determine the __vtbl location, but I'm not  
sure if there's a way in compile-time to get the __vtbl index to use.  I  
suppose you could iterate over the vtbl entries and find the function that  
matches.  It would be O(n) to construct the call function, but O(1) to  
call it.


-Steve

Re: Does D have too many features?

[Jonathan M Davis]

On Thursday, May 03, 2012 13:43:11 Sean Kelly wrote:
> On May 3, 2012, at 1:11 PM, Don wrote:
> > On 03.05.2012 21:08, Sean Kelly wrote:
> >> On May 3, 2012, at 8:13 AM, Don Clugston wrote:
> >>> On 03/05/12 16:13, Andrei Alexandrescu wrote:
>  Good ones. In fact I even discounted them from this discussion because
>  I'd already considered them gone. Walter agreed that I don't mention
>  them in TDPL, with the intent to have them peter out.
>  
>  One good step right now would be to remove NCEG operators from the
>  online documentation. Later on, we'll consider them an accept-invalid
>  bug :o).
> >>> 
> >>> Well, they are also used in druntime, in core.stdc.math
> >>> 
> >>> BTW I *hate* that module, I don't know why it exists. Even worse, it
> >>> seems to be growing -- people are adding more things to it. Practically
> >>> everything in there has a better implementation in std.math.>> 
> >> core.stdc.math corresponds to C99's math.h and is there as a part of the
> >> standard C interface. It should only contain the required C99
> >> prototypes, and in some cases functions if the C implementation is a
> >> macro. If there is anything nonstandard in there, I'm not aware of it.> 
> > Yes, but why do we have it? We're not C.
> 
> Mostly because it was handy to fall back on the C API before Phobos was so
> well fleshed-out. Today, I think it mostly exists to ease porting of C
> apps.

In principle, having prototypes for the entire standard C library in druntime 
seems like a good idea to me. In practice though, it could cause problems due 
to people using the C functions rather than the D functions for some things 
(e.g. the math functions). If we properly documented them all though, we could 
then put comments about the correct D function to use to replace each C 
function which has a D replacement, and then it could actually help people 
move away from the C functions.

- Jonathan M Davis

Re: virtual method pointer

[Steven Schveighoffer]

On Thu, 03 May 2012 16:57:01 -0400, deadalnix  wrote:


Le 03/05/2012 22:22, Gor Gyolchanyan a écrit :

That workaround is pretty obvious, but I can't afford to make an extra
call every time. This event system is supposed to be ultra-fast. Isn't
there a way to get to the vtable etry itself?


1/ Such a trivial thing is surely inlined by any compiler with  
optimizations on.


I wouldn't count on it.  You can't inline a lambda that is used somewhere  
it's not declared.



2/ You can afford a virtual dispatch, but can't afford a function call ?


In my experience, virtual calls are nearly as cheap as normal calls.  But  
doubling the function call setup/teardown/call is not insignificant.  It  
all depends on how much time is spent in the function being called.



I do think you are in case of premature optimizations here.


This is very likely, it all depends on what you are doing *inside* the  
call.


-Steve

Re: Does D have too many features?

[deadalnix]

Le 03/05/2012 22:43, Sean Kelly a écrit :

On May 3, 2012, at 1:11 PM, Don wrote:


On 03.05.2012 21:08, Sean Kelly wrote:

On May 3, 2012, at 8:13 AM, Don Clugston wrote:


On 03/05/12 16:13, Andrei Alexandrescu wrote:



Good ones. In fact I even discounted them from this discussion because
I'd already considered them gone. Walter agreed that I don't mention
them in TDPL, with the intent to have them peter out.

One good step right now would be to remove NCEG operators from the
online documentation. Later on, we'll consider them an accept-invalid
bug :o).


Well, they are also used in druntime, in core.stdc.math

BTW I *hate* that module, I don't know why it exists. Even worse, it seems to 
be growing -- people are adding more things to it.
Practically everything in there has a better implementation in std.math.


core.stdc.math corresponds to C99's math.h and is there as a part of the 
standard C interface.  It should only contain the required C99 prototypes, and 
in some cases functions if the C implementation is a macro.  If there is 
anything nonstandard in there, I'm not aware of it.


Yes, but why do we have it? We're not C.


Mostly because it was handy to fall back on the C API before Phobos was so well 
fleshed-out.  Today, I think it mostly exists to ease porting of C apps.


So they probably belongs to deimos.

Re: virtual method pointer

[Gor Gyolchanyan]

Basically I want to make a dynamic typing subsystem in D. I want to
take a given object of a static type, construct a dynamic interface
for it and later use that interface to event handling.
To construct a dynamic interface, I need to extract the virtual
methods without resolving them prematurely.

On Fri, May 4, 2012 at 1:11 AM, Steven Schveighoffer
 wrote:
> On Thu, 03 May 2012 16:57:01 -0400, deadalnix  wrote:
>
>> Le 03/05/2012 22:22, Gor Gyolchanyan a écrit :
>>>
>>> That workaround is pretty obvious, but I can't afford to make an extra
>>> call every time. This event system is supposed to be ultra-fast. Isn't
>>> there a way to get to the vtable etry itself?
>>
>>
>> 1/ Such a trivial thing is surely inlined by any compiler with
>> optimizations on.
>
>
> I wouldn't count on it.  You can't inline a lambda that is used somewhere
> it's not declared.
>
>
>> 2/ You can afford a virtual dispatch, but can't afford a function call ?
>
>
> In my experience, virtual calls are nearly as cheap as normal calls.  But
> doubling the function call setup/teardown/call is not insignificant.  It all
> depends on how much time is spent in the function being called.
>
>
>> I do think you are in case of premature optimizations here.
>
>
> This is very likely, it all depends on what you are doing *inside* the call.
>
> -Steve



-- 
Bye,
Gor Gyolchanyan.

Re: Does D have too many features?

[Era Scarecrow]

On Thursday, 3 May 2012 at 20:36:47 UTC, Jonathan M Davis wrote:

On Thursday, May 03, 2012 15:30:40 Don Clugston wrote:

What is this D3 thing 
As far as I can tell, 'D3' was invented by newcomers to the 
forums.


I think that what it comes down to is that there are a variety 
of people who
want features added or changed in D which are either not going 
to happen
anytime soon or will never happen in D2 (especially if they're 
major breaking
changes). So, they figure/hope that we'll have a new revision 
of the language
where we'll be able to make breaking changes and then maybe the 
changes that
they want will make it in then. After all, particularly from 
the perspective
of a newbie, we already had D2 which changed a bunch of stuff 
from D1, why
wouldn't we have D3 later on? And for folks who really want to 
see changes
that aren't going to happen, the idea that we're going to have 
another major
revision of the language which might make the changes that they 
want sounds

really appealing.

I think that Walter and Andrei have made it fairly clear when 
they've said
anything on the subject that there is no intention to make any 
kind of D3
anytime soon and that if we do, it'll be years from now after 
D2 is mature and
well-established, and it actually makes sense to do a new major 
revision. But
I do think that you're right in that the very idea of a D3 was 
created by
folks in the newsgroup. Walter and the other developers have 
been focusing on
stabilizing D2 as _the_ version of the language, not finishing 
it up so that
they can move onto D3. And the misconceptions about D1 that 
you've pointed out
in the past probably just help contribute to the idea that 
we'll have a D3 at
some point. Maybe we will, maybe we won't, but there's no point 
in worrying

about it for years yet.


 If anything, I would consider D3 an ideal, something to work 
towards. And no it wouldn't be started or really worked on for at 
10-15 years after D's mature and at Andrei's goal of having at 
least a million users. And as stated before, if there [b]IS[/b] 
going to be a D3 at any point it should have no problem calling 
D2 code.


 Course thinking of D3 now is kinda like thinking of flying cars 
and how you want a flying car and you won't buy a car today until 
it can fly...  Back (in the 50-60's was it?) they thought we 
would be having a flying car for every family and had these 
really badly done animations of what they expected to see. I 
don't see any flying cars outside of Hollywood. Best if we stick 
in the present and deal with our problems now.

Re: scope ref const(T) --> error?!

[Tove]

On Thursday, 3 May 2012 at 18:28:19 UTC, Mehrdad wrote:

What's wrong with passing a struct as scope ref const?

I want to avoid copying the struct, and its information is only 
read inside the function...


ref scope? hm? What additional semantics do you desire from that 
construct, which 'const ref' doesn't provide?


A a;

void fun(const scope ref A x)
{
  // x goes out of scope, destroy it... oops it's a global 
variable!?

}

fun(a);

Re: Growing pains

[H. S. Teoh]

On Thu, May 03, 2012 at 01:51:20PM -0700, Ali Çehreli wrote:
> On 05/03/2012 01:52 PM, deadalnix wrote:
> >Le 03/05/2012 16:50, Andrei Alexandrescu a écrit :
> >>Just letting you all know we're working on the frustrating and
> >>increasingly frequent "Load at xx.xx, try again later" errors when
> >>reading this forum through NNTP. They are caused by a significant
> >>growth spurt in newsgroup readership that occurred in recent times.
> >>We are working with our provider to fix these issues.
[...]
> >I love you :D
> >
> >It was so anoying when posting a message and *pof* « error your
> >message is lost ».
> 
> I've learned years ago to never trust a web page or a browser.

+1.


> I always type inside the Emacs *scratch* buffer and then copy and
> paste from there to the browser window. (I did it again! :) Actually
> no, this is a Thunderbird window, but still...)
[...]

Or just use a sane email client like Mutt and subscribe to the mailing
list instead. :-)


T

-- 
Life is unfair. Ask too much from it, and it may decide you don't deserve what 
you have now either.

Re: scope ref const(T) --> error?!

[Ali Çehreli]

On 05/03/2012 03:21 PM, Tove wrote:
> On Thursday, 3 May 2012 at 18:28:19 UTC, Mehrdad wrote:
>> What's wrong with passing a struct as scope ref const?
>>
>> I want to avoid copying the struct, and its information is only read
>> inside the function...
>
> ref scope? hm? What additional semantics do you desire from that
> construct, which 'const ref' doesn't provide?

scope is a not-yet-implemented promise of the function. It says: "trust 
me, I will not use this reference outside of the function."


> A a;
>
> void fun(const scope ref A x)
> {
> // x goes out of scope, destroy it... oops it's a global variable!?

scope does not destroy. scope makes this illegal (assuming that A is a 
class type):


a = x;

There is deprecated use of the 'scope' keyword but this is not it.

> }
>
> fun(a);
>

Ali

Re: Does D have too many features?

[H. S. Teoh]

On Thu, May 03, 2012 at 11:32:52PM +0200, Era Scarecrow wrote:
[[...]
>  If anything, I would consider D3 an ideal, something to work
> towards. And no it wouldn't be started or really worked on for at
> 10-15 years after D's mature and at Andrei's goal of having at least
> a million users. And as stated before, if there [b]IS[/b] going to
> be a D3 at any point it should have no problem calling D2 code.

Do we know (roughly) how many D users are out there right now?


>  Course thinking of D3 now is kinda like thinking of flying cars and
> how you want a flying car and you won't buy a car today until it can
> fly...  Back (in the 50-60's was it?) they thought we would be
> having a flying car for every family and had these really badly done
> animations of what they expected to see. I don't see any flying cars
> outside of Hollywood. Best if we stick in the present and deal with
> our problems now.

There aren't any flying cars in Hollywood either. They're either just
artist's concepts (*cough*CGI models*cough*), held up by strings, or
just superimposed on an animated background.


T

-- 
It is not the employer who pays the wages. Employers only handle the money. It 
is the customer who pays the wages. -- Henry Ford

Re: scope ref const(T) --> error?!

[Tove]

On Thursday, 3 May 2012 at 22:25:45 UTC, Ali Çehreli wrote:

On 05/03/2012 03:21 PM, Tove wrote:
> On Thursday, 3 May 2012 at 18:28:19 UTC, Mehrdad wrote:
>> What's wrong with passing a struct as scope ref const?
>>
>> I want to avoid copying the struct, and its information is
only read
>> inside the function...
>
> ref scope? hm? What additional semantics do you desire from
that
> construct, which 'const ref' doesn't provide?

scope is a not-yet-implemented promise of the function. It 
says: "trust me, I will not use this reference outside of the 
function."


> A a;
>
> void fun(const scope ref A x)
> {
> // x goes out of scope, destroy it... oops it's a global
variable!?

scope does not destroy. scope makes this illegal (assuming that 
A is a class type):


a = x;

There is deprecated use of the 'scope' keyword but this is not 
it.


> }
>
> fun(a);
>

Ali


right, thanks. I forgot about that, since it was never 
implemented I didn't use it.


But nevertheless... the actual implemented semantics is the same 
for parameters as for the deprecated function body case, at the 
end of the function the parameter goes out of scope too! i.e. 
destructor should be called.

GSOC Linker project

[Pierre LeMoine]

Hi!

I'm interested in starting a project to make a linker besides 
optlink for dmd on windows. If possible it'd be cool to run it as 
a gsoc-project, but if that's not an option I'll try to get it 
admitted as a soc-project at my university.


Anyway, the project would aim to be a replacement or alternative 
to optlink on windows. I've personally encountered quite a few 
seemingly random problems with optlink, and the error messages 
are not exactly friendly. My vision is to create a linker in a 
relatively modern language (D) and to release the project as open 
source.


So, I'm curious about some things; Is it too late to get this 
accepted as a summer of code project? Are there any current 
alternative linkers for dmd on windows, or any current projects 
aiming to create one? And do any of you know of a "Everything you 
need to know to write the best linker ever" resource center? ;]


/Pierre

Re: Growing pains

[Walter Bright]

On 5/3/2012 1:52 PM, deadalnix wrote:

It was so anoying when posting a message and *pof* « error your message is lost 
».


Youch. I didn't realize that was happening. I post from Thunderbird, and if it 
fails you just try it again.


Anyhow, thanks to Jan Knepper for hosting us and figuring out a solution.

Re: GSOC Linker project

[Alex Rønne Petersen]

On 04-05-2012 00:47, Pierre LeMoine wrote:

Hi!

I'm interested in starting a project to make a linker besides optlink
for dmd on windows. If possible it'd be cool to run it as a
gsoc-project, but if that's not an option I'll try to get it admitted as
a soc-project at my university.


Absolutely possible, though too late for this year's GSoC. If you're 
still interested in working on it for GSoC 2013 (if Google decides to do 
another GSoC (which they most likely will)), then be sure to submit a 
proposal!




Anyway, the project would aim to be a replacement or alternative to
optlink on windows. I've personally encountered quite a few seemingly
random problems with optlink, and the error messages are not exactly
friendly. My vision is to create a linker in a relatively modern
language (D) and to release the project as open source.


Sounds like a good idea to me. Though in my personal opinion, you should 
try to make the linker as platform-agnostic as possible, so it's easy to 
adapt for new platforms / file formats.




So, I'm curious about some things; Is it too late to get this accepted
as a summer of code project? Are there any current alternative linkers
for dmd on windows, or any current projects aiming to create one? And do
any of you know of a "Everything you need to know to write the best
linker ever" resource center? ;]


Too late for this year's GSoC.

For another linker option, see Unilink.

As for resources on linkers, I think your best bet is reading the LLVM 
and GCC source code. I think someone also started an LLVM (machine code) 
linker project recently, but I don't know where to find it.




/Pierre


--
- Alex

Re: Growing pains

[Alex Rønne Petersen]

On 04-05-2012 00:47, Walter Bright wrote:

On 5/3/2012 1:52 PM, deadalnix wrote:

It was so anoying when posting a message and *pof* « error your
message is lost ».


Youch. I didn't realize that was happening. I post from Thunderbird, and
if it fails you just try it again.


I use Thunderbird too, and one of my messages actually *did* get lost. I 
wrote the message, hit send, and then right after it "finished" sending 
the message, an NG error popped up and the message was lost.


As far as I can see, Thunderbird doesn't save sent NNTP messages 
anywhere unless you explicitly tell it to. :(




Anyhow, thanks to Jan Knepper for hosting us and figuring out a solution.


--
- Alex

Re: Does D have too many features?

[Walter Bright]

On 5/3/2012 8:13 AM, Don Clugston wrote:

Well, they are also used in druntime, in core.stdc.math
BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be
growing -- people are adding more things to it.


It's there simply because all the Standard C headers should be represented. It 
should not get anything that is not in Standard C. Ditto for all the other stuff 
in core.stdc.


It's there to make converting C code to D code easier.


Practically everything in there has a better implementation in std.math.


Yup. But also note that the only "implementations" in there are things that are 
done as macros in C's math.h, meaning they're trivial.

Re: Growing pains

[Vladimir Panteleev]

On Thursday, 3 May 2012 at 20:45:24 UTC, deadalnix wrote:
It was so anoying when posting a message and *pof* « error 
your message is lost ».


For the record: forum.dlang.org doesn't do this.

Re: Does D have too many features?

[Era Scarecrow]

On Thursday, 3 May 2012 at 22:29:47 UTC, H. S. Teoh wrote:

On Thu, May 03, 2012 at 11:32:52PM +0200, Era Scarecrow wrote:
Do we know (roughly) how many D users are out there right now?


 Don't know. Need a poll :) I'm definitely sure we have at least 
10 users; beyond that I can only speculate; Maybe 2 to the power 
of ten or thirteen...


There aren't any flying cars in Hollywood either. They're 
either just artist's concepts (*cough*CGI models*cough*), held 
up by strings, or just superimposed on an animated background.


 Exactly! It's on the 'big screen', meaning smoke and gimmicks, 
the same as magicians.


 Anyways, focus on the now. D3 may/will come some day, but that's 
a long ways off. Course if you plan early for certain things that 
will change it does make going towards it easier with language 
design, or give you more time to think about faults and fixes.

Re: Does D have too many features?

[H. S. Teoh]

On Fri, May 04, 2012 at 01:12:20AM +0200, Era Scarecrow wrote:
> On Thursday, 3 May 2012 at 22:29:47 UTC, H. S. Teoh wrote:
> >On Thu, May 03, 2012 at 11:32:52PM +0200, Era Scarecrow wrote:
> >Do we know (roughly) how many D users are out there right now?
> 
>  Don't know. Need a poll :) I'm definitely sure we have at least 10
> users; beyond that I can only speculate; Maybe 2 to the power of ten
> or thirteen...

Only 10?? Judging from mailing list membership, I'd say at least 25 or
30, just on the forums alone. I'm assuming that people here aren't
subscribed just for kicks, they actually write D code. There are
probably more outside the forums (somebody mentioned an entire company
of D programmers before, perhaps about 50-100? I don't remember the
exact figure). There's got to be more out there, given that Andrei has
been giving talks about D for a while. *Somebody* in the audience must
be actually listening to what he says.

But in any case, I'd say we have a ways to go yet in terms of D
adoption.


[...]
>  Anyways, focus on the now. D3 may/will come some day, but that's a
> long ways off. Course if you plan early for certain things that will
> change it does make going towards it easier with language design, or
> give you more time to think about faults and fixes.

Yep.


T

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.

Re: GSOC Linker project

[Trass3r]

I'm interested in starting a project to make a linker besides optlink  
for dmd on windows.


Imho changing dmd to use COFF (incl. 64 support) instead of that crappy  
OMF would be more beneficial than yet another linker.



My vision is to create a linker in a relatively modern language (D) and  
to release the project as open source.


If you do write a linker then make it cross-platform right from the start;  
and modular so it can support all object file formats.

Re: Growing pains

[Nick Sabalausky]

"deadalnix"  wrote in message 
news:jnuqp4$2hs8$1...@digitalmars.com...
>
> It was so anoying when posting a message and *pof* « error your message is 
> lost ».

That's one of the reasons I avoid web-based things whenever possible.

Re: Growing pains

[Nick Sabalausky]

"Alex Rønne Petersen"  wrote in message 
news:jnv2c1$319r$2...@digitalmars.com...
>
> As far as I can see, Thunderbird doesn't save sent NNTP messages anywhere 
> unless you explicitly tell it to. :(
>

Outlook Express does ;)

Re: From Ada 2012

[bearophile]

Paulo Pinto:

but thanks to the increase in security concern in software, 
actually it seems to be picking up users in Europe, for projects 
where human lifes are at risk.<


Recently I am seeing a little grow of the interest in Ada. Maybe 
they have accepted that despite the flaws of Ada, it's the best 
tool for certain purposes. But more probably, several other more 
important factors are at play, probably political too.



But D would, of course, be an easier upgrade path for C or C++ 
developers.<


In my opinion for a decent C or C++ programmer it's not too much 
hard to learn the Zen of Ada, they share similar roots (Ada is 
closer to Pascal, C++ closer to C, but the paradigms used are 
similar. Example: Ada templates require explicit instantiation, 
but learning this doesn't require a C++ programmer to change 
his/her/hir brain a lot).


D seems fit to write videogame engines, but despite D is safer 
than C and C++, for high integrity software, I think D will need 
an external tool that enforces very strict safe coding standards, 
because @safe can't be enough. Example: on default Ada all 
integral values don't overflow silently. Another example: there 
are strict and safe built-in ways to use multi-cores. Another 
example: kinds of pointers.


I have not used Ada a lot, but I like how you usually define 
(strong) types for most classes of variables, like for integral 
values, each with their range, if they are sub-ranges (subtypes) 
of other strong ranges, and so on.


A small example. If you have two matrices, where one contains 
(r,c) row-column pairs of indexes of the other matrix, it's easy 
to enforce the tuple items to be inside the number of rows or 
columns of the other matrix. If the second matrix has to contain 
only positive values, plus let's say the -3 -2 and -1 values to 
signal special cases, it's easy to define such integral type, and 
so on. And the compiler will verify things at compile-time where 
possible (example: If you write a literal of a string of 
enumerated chars, or the second matrix, it will verify at 
compile-time that the values of the literal are in the specified 
ranges), and insert out of range tests for run-time. Such range 
kinds and tests don't require advanced type system features to be 
implemented by the Ada compilers, but they are able to catch a 
lot of bugs early, that in C/C++/D bite you often. In most C++ 
code I've seen there is not even a bit of such strong static 
typing of the integral values. This makes the code harder to 
modify, and just "int" used for ten different purposes makes it 
easy to use an integral variable where a totally different one 
was needed, this turns the C++/D code into a "soup" that's buggy 
and harder to debug. I don't like the carefree attitude of 
C-style languages regarding strong typing of integral values. I 
have seen that computer language features 30+ years old are able 
to avoid most of such troubles.


In functional languages as Haskell and F# such work on indexes 
and ranged values and so on is much less needed, but in 
high-performance Ada/C/C++/Delphi/D coding, they are used quite 
often.


Bye,
bearophile

Re: GSOC Linker project

[H. S. Teoh]

On Fri, May 04, 2012 at 12:53:02AM +0200, Alex Rønne Petersen wrote:
> On 04-05-2012 00:47, Pierre LeMoine wrote:
[...]
> >Anyway, the project would aim to be a replacement or alternative to
> >optlink on windows. I've personally encountered quite a few seemingly
> >random problems with optlink, and the error messages are not exactly
> >friendly. My vision is to create a linker in a relatively modern
> >language (D) and to release the project as open source.
> 
> Sounds like a good idea to me. Though in my personal opinion, you
> should try to make the linker as platform-agnostic as possible, so
> it's easy to adapt for new platforms / file formats.
[...]

The problem with writing linkers is that they are usually closely tied
to implementation details on the host OS. At the very least, they must
play nice with the OS's runtime dynamic linker (or *be* the dynamic
linker themselves, like ld on the *nixes). They must also play nice with
object files produced by other compilers on that platform, since
otherwise it sorta defeats the purpose of rewriting optlink in the first
place. This means that they must understand all the intimate details of
every common object file and executable format on that OS.

The basic concept behind a linker is very simple, really, but it's the
implementation where details get ugly.

To be frank, I question the wisdom of not just using ld on Posix
systems... but OTOH, the world *needs* better linker technology than we
currently have, so this projects like this one is a good thing.

Linkers date from several decades ago, where programs can be broken up
into separate, self-contained source files in a simple way. Things have
changed a lot since then.  Nowadays, we have template functions, virtual
functions, dynamic libraries, etc., which require hacks like weak
symbols to work properly. And we're *still* missing a sound conceptual
framework for things like cross-module dead code elimination,
cross-module template instantiation, duplicate code merging (like
overlapping immutable arrays), etc.. These things _sorta_ work right
now, but they're sorta hacked on top of basic 30-year-old linker
technology, rather than being part of a sound, conceptual linker
paradigm.


T

-- 
There are 10 kinds of people in the world: those who can count in binary, and 
those who can't.

Re: Growing pains

[H. S. Teoh]

On Thu, May 03, 2012 at 07:50:30PM -0400, Nick Sabalausky wrote:
> "Alex R�nne Petersen"  wrote in message 
> news:jnv2c1$319r$2...@digitalmars.com...
> >
> > As far as I can see, Thunderbird doesn't save sent NNTP messages
> > anywhere unless you explicitly tell it to. :(
[...]

I'm skeptical of all GUI-based mail clients. But that's just me. :-)


> Outlook Express does ;)
[...]

Ewww!!


T

-- 
It is widely believed that reinventing the wheel is a waste of time; but
I disagree: without wheel reinventers, we would be still be stuck with
wooden horse-cart wheels.

Re: Does D have too many features?

[Sean Kelly]

On May 3, 2012, at 2:16 PM, deadalnix  wrote:

> Le 03/05/2012 22:43, Sean Kelly a écrit :
>> On May 3, 2012, at 1:11 PM, Don wrote:
>> 
>>> On 03.05.2012 21:08, Sean Kelly wrote:
 On May 3, 2012, at 8:13 AM, Don Clugston wrote:
 
> On 03/05/12 16:13, Andrei Alexandrescu wrote:
>> 
>> 
>> Good ones. In fact I even discounted them from this discussion because
>> I'd already considered them gone. Walter agreed that I don't mention
>> them in TDPL, with the intent to have them peter out.
>> 
>> One good step right now would be to remove NCEG operators from the
>> online documentation. Later on, we'll consider them an accept-invalid
>> bug :o).
> 
> Well, they are also used in druntime, in core.stdc.math
> 
> BTW I *hate* that module, I don't know why it exists. Even worse, it 
> seems to be growing -- people are adding more things to it.
> Practically everything in there has a better implementation in std.math.
 
 core.stdc.math corresponds to C99's math.h and is there as a part of the 
 standard C interface.  It should only contain the required C99 prototypes, 
 and in some cases functions if the C implementation is a macro.  If there 
 is anything nonstandard in there, I'm not aware of it.
>>> 
>>> Yes, but why do we have it? We're not C.
>> 
>> Mostly because it was handy to fall back on the C API before Phobos was so 
>> well fleshed-out.  Today, I think it mostly exists to ease porting of C apps.
> 
> So they probably belongs to deimos.

Except that they're used by druntime, both explicitly and publicly imported by 
core.sys.posix. 

Re: Does D have too many features?

[Era Scarecrow]

On Thursday, 3 May 2012 at 23:40:32 UTC, H. S. Teoh wrote:
Only 10?? Judging from mailing list membership, I'd say at 
least 25 or 30, just on the forums alone. I'm assuming that 
people here aren't subscribed just for kicks, they actually 
write D code. There are probably more outside the forums 
(somebody mentioned an entire company of D programmers before, 
perhaps about 50-100? I don't remember the exact figure). 
There's got to be more out there, given that Andrei has been 
giving talks about D for a while. *Somebody* in the audience 
must be actually listening to what he says.


 I was being sarcastic :P