date:20151008

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

  Issue ID: 15177
   Summary: mixin + traits issue with 2.069 beta 1
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: tri...@katamail.com

Created attachment 1555
  --> https://issues.dlang.org/attachment.cgi?id=1555=edit
Source code. Test it running 'dub'.

I get a strange error with dmd 2.069 b1.
I can't understand what happen exactly but apparently traits allMember return
an unrelated symbol.

I reduced code using dustmite and manually. 

Attached code compile for me using dmd 2.068 on linux x64. 

Using dmd 2.069 b1 it fails:
source/tests/utils.d-mixin-13(13): Error: undefined identifier
'_D32TypeInfo_S7asserts12AssertResult6__initZ'

--

Re: Beta D 2.069.0-b1

2015-10-08 Thread lobo via Digitalmars-d-announce


On Thursday, 8 October 2015 at 09:17:16 UTC, Martin Nowak wrote:

On Thursday, 8 October 2015 at 04:53:53 UTC, Suliman wrote:

Is it DDMD based release?


Yes.


Is there any info on the benchmarking between DDMD and DMD?

bye,
lobo

PS: Big thanks for the much improved release process that you 
guys are maintaining.

[Issue 12558] try/catch allows implicit catching of Errors without specifying any Exception type

2015-10-08 Thread Andrea Fontana via Digitalmars-d-announce

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

--- Comment #12 from Andrej Mitrovic  ---
I'll recreate the pull today or tomorrow.

I'll do the same for the other stale pulls of mine in the coming days.

--

Re: Beta D 2.069.0-b1


On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

First beta for the 2.069.0 release.

http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.069.0.html


Please report any bugs at https://issues.dlang.org

-Martin


Got an issue:
https://issues.dlang.org/show_bug.cgi?id=15177

It's really strange and difficult to reduce for me...

Re: Tell GC to use shared memory

2015-10-08 Thread tcak via Digitalmars-d-learn


On Thursday, 8 October 2015 at 05:46:31 UTC, ketmar wrote:

On Thursday, 8 October 2015 at 04:38:43 UTC, tcak wrote:
Is it possible to modify GC (without rebuilding the compiler), 
so it uses a given shared memory area instead of heap for 
allocations?


sure. you don't need to rebuild the compiler, only druntime.


Any better solution? Like overriding GC class, etc.

Re: D 2015/2016 Vision?

2015-10-08 Thread Robert burner Schadek via Digitalmars-d

On Tuesday, 6 October 2015 at 20:31:58 UTC, Jonathan M Davis 
wrote:
I don't think the problem is with structs. The problem is that 
programmers coming from other languages default to using 
classes. The default in D should always be a struct. You use a 
class because you actually need inheritance or because you want 
to ensure that a type is always a reference type and don't want 
to go to the trouble of writing a struct that way (and even 
then, you should probably just write the struct that way).


Hmm... If we must emulate reference semantics manually, it feels 
like C++ with explicit references, pointers and all sorts of 
smart pointers, and obviates need for classes being reference 
types: just emulate reference semantics as we must do it anyway.

Voting for std.experimental.testing

This is the voting thread for inclusion of 
std.experimental.testing into phobos.


PR: https://github.com/D-Programming-Language/phobos/pull/3207
Dub: http://code.dlang.org/packages/unit-threaded
Doc: See CyberShadow/DAutoTest for up-to-date documentation build
Formal Review Thread: 
http://forum.dlang.org/post/stbdckpfsysjtppld...@forum.dlang.org
Previous Thread: 
http://forum.dlang.org/post/uzocokshugchescba...@forum.dlang.org


Please respond to this post with a comment starting with a single 
"Yes"/"No" and optional explanation after that. Criteria you are 
expected to evaluate as part of "Yes":


- is this functionality needed in Phobos
- is basic design sound (some breaking changes are OK for 
std.experimental but not full redesign)


As usual, anyone can vote, but opinions of Phobos developers hold 
more value.


Voting ends in 2 weeks, on Oktober 22.

D Language Implementation of DIgitalOcean API

2015-10-08 Thread Laeeth Isharc via Digitalmars-d-announce


I'm sorry, but I posted in the wrong group before.

Digital Ocean provide cloud infrastructure (KVM servers).  They 
serve a somewhat different market to Amazon's AWS and similar 
offering a much less complex product for a significantly lower 
price (especially if you pay the sticker price for Amazon).  
Unlike some other VPN providers, their servers are fast and my 
experience and that of others has been there is less contention 
for resources compared to some alternative lower-priced providers.


https://www.digitalocean.com/features/technology/
https://www.digitalocean.com/pricing/
$10/mo for 1GB RAM + 30 Gb SSD

I have ported their API v2 to D.  It's not very well-tested for 
the time being, and given the conceivable risks if your software 
should go haywire, it might not be a good idea to use in 
production just yet.  But perhaps somebody may find it useful.


Link to the code.dlang.org is here:
http://code.dlang.org/packages/digitalocean_api

DNSMadeEasy API coming up.


Laeeth.

Re: D and microservices

2015-10-08 Thread Ola Fosheim Grøstad via Digitalmars-d


On Thursday, 8 October 2015 at 03:12:03 UTC, Martin Nowak wrote:
We might be able to reuse the existing delegate capture 
mechanism to create continuations.
Then await would "simply" rewrite the rest of the body as 
delegate, similar to how the foreach body can be transformed 
into a delegate.


Not sure how that works? What is needed is to preallocate a 
"continuation" that is large enough to cover all "stack 
allocated" state that has to be retained when the coroutine 
yields, at all yield points. But with reuse of memory for dead 
variables (like in optimized stack usage where you reuse stack 
memory that is dead). Then use those areas of the continuation 
during computation rather than the stack.


So basically all functions that may yield have to be available 
for static analysis before you start up the coroutine and all 
reachable yield points have to be analysed. So you basically have 
one big stack frame at the "top of the stack" as a separate 
object (the "continuation") and everything that has to survive a 
yield has to go onto that frame.


That's how I would do it anyway.

There is some use-case for HPC code where stackless coroutines 
make a huge differences (used with a work stealing scheduler), 
for basic networking code it will only be a small difference.


The current D implementation can run out of stack. That's much 
less of an issue if the system/thread stack is used in 
combination with a fixed size preallocated "continuation".

Re: Shout out to D at cppcon, when talkign about ranges.

2015-10-08 Thread Trass3r via Digitalmars-d


Here's the original discussion with Eric's elaborate answer:
http://ericniebler.com/2014/02/21/introducing-iterables/#comment-403

Because I want to leverage the vast amount of iterator-based 
code already written, and because in my experience, I don’t 
find that ranges as primitives solve all the problems that 
iterators do.


Many algorithms return positions. These all suffer the same 
problem as find. One algorithm implementation isn’t sufficient; 
you need bunches of differently-named algorithms that differ 
only in the subrange they return.


As for the political argument: I want ranges in the standard. 
There is just no way the C++ standardization committee would 
ever consider a range-only interface.

Re: D and microservices

2015-10-08 Thread Laeeth Isharc via Digitalmars-d

On Wednesday, 7 October 2015 at 10:50:47 UTC, Russel Winder wrote:
On Tue, 2015-10-06 at 18:56 +, Dicebot via Digitalmars-d 
wrote:
On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder 
wrote:
> Has anyone got a small example of microservices using D, 
> with Vibe.d or otherwise, that I can make use of? I need 
> some examples of small microservices for a session at μCon 
> 2015.

What do you mean by microservice examples? It is 
infrastructure methodology, not specific code thing, any 
simple network service can be viewed as microservice.

At the Web services application level it is having a small 
framework for structuring the use of GET, POST, PUT, DELETE,… 
packets. Basically RESTful services.

At a non HTTP level I guess you can say all networking is 
microservices except that you want a protocol over TCP/IP or 
UDP/IP and shouldn't there be frameworks to assist building 
these things?

Zeromq plus msgpack or the like (maybe cerealed!) gives you quite 
a lot.  I use nanomsg, which is still beta but nicer in some 
ways.  In any case it gives you survey, request/reply, bus, 
publish / subscribe patterns.  And it's very light and has decent 
throughput.  What kind of framework were you thinking of ?  
(nanomsg doesn't do UDP, but I think zeromq does.  You can write 
your own protocol or pattern if the existing ones don't work for 
you, and sounds like that's work, but not much more than it needs 
to be).

Re: Beta D 2.069.0-b1

2015-10-08 Thread Martin Nowak via Digitalmars-d-announce


On Thursday, 8 October 2015 at 04:53:53 UTC, Suliman wrote:

Is it DDMD based release?


Yes.

Check template parameter whether it has "length"

2015-10-08 Thread tcak via Digitalmars-d-learn

I am "trying" to write a function that takes an array of items, 
and returns the length of longest item.


[code]
size_t maxLength(A)( const A[] listOfString ) if( __traits( 
hasMember, A, "length" ) )

{
return 0; // not implemented yet
}
[/code]

I tried it with

if( __traits( compiles, A.length ) )

as well. But compiler doesn't match it.

writeln("Max Length: ", maxLength( ["foo", "123456789"] ));

Compilers says it cannot deduce function from argument types ...

I do not want to check whether the type "A" is string, char[], 
etc. As long as it has length (please do not put me into ranges, 
library functions etc as much as possible), I want the function 
to accept it.

Re: Beta D 2.069.0-b1

2015-10-08 Thread Andrea Fontana via Digitalmars-d-announce


On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote:
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak 
wrote:

First beta for the 2.069.0 release.

http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.069.0.html


Please report any bugs at https://issues.dlang.org

-Martin


`The -property switch has been deprecated.` Does that mean 
@property has no effect anymore ?


--Stephan


From changelog:

"The -property switch used to disallow calling non-properties 
without parentheses. The switch has not been used to build Phobos 
for some time now. So naturally, code that's incompatible with 
-property has found its way in. This means, the switch has 
effectively not been supported by D at large.


Since the behaviour of the -property switch was not well-liked, 
it's been deprecated and made to have no effect when used."

Re: D and microservices

2015-10-08 Thread Joakim via Digitalmars-d


On Thursday, 8 October 2015 at 06:43:24 UTC, Laeeth Isharc wrote:
In any case, we have now inconceivable amounts of computing 
power on tap for very affordable prices and the tools to manage 
it.  When a little instance is 0.7 cents an hour, and a usable 
one is 1.5 cents and you can scale up and down as quickly as 
you like, many things become possible that weren't before.  The 
world is only slowly beginning to figure out what, judging by 
what I see in finance.


It is amazing how much compute is on tap these days and we do 
almost nothing with it.  Forget about the cloud, just look at how 
powerful all these mobile devices are.  The problem is that 
software development has lagged leagues behind hardware 
development.


Since I am foolish enough to run my own mail server, you can be 
sure that my sympathies are with you.


I used to do that, but what would stop them from getting into 
your server either?  Just as they go after email hosts, they can 
go after server hosts.  Unless you're running it out of your own 
house, which has other problems, most notably port-blocking by 
ISPs.


I think people are reckless - both individuals and corporations 
- in what they unthinkingly cede to companies that really have 
few incentives to act as one might wish.  It's one thing to be 
the customer, and quite another to be the product.  I saw Eric 
Schmidt speak some years back, and he really didn't give me a 
feeling that we have a similar idea about what evil means!


They are reckless until they're personally hurt by it.  There 
will be a backlash when some scandal or hack forces people to 
change.  The recent ad-blocking and router security scandals are 
good examples, both of which have been festering for a _long_ 
time:


http://fortune.com/2015/09/20/apple-ad-block-ios9/
http://blog.codinghorror.com/welcome-to-the-internet-of-compromised-things/

within the enterprise often being rather different.  Things 
even in quite small firms of 150+ people start being more about 
internal bureaucratic logic and much less about ROI.  And the 
problem is that it's hard to make a convincing case for 
something that doesn't yet exist, and yet many big things have 
the tiniest beginnings.  So the current enterprise technology 
environment discourages those little experiments that drive 
real innovation, as well as getting in the way of larger 
projects.


Interesting article along the same vein, that goes in a fairly 
radical direction until near the end, when it shifts course to 
point out how Apple is trying to account for this:


http://www.asymco.com/2015/08/31/fluid-coupling/

The cloud, by commoditising compute, and making the price much 
more transparent then is a force for breaking down central 
structures that no longer serve their needs well.  When you can 
get whatever you need from Amazon today, waiting months and 
paying 10x more starts to seem a little stiff, and people start 
asking questions when before they had no choice but to grin and 
bear it.  Of course the questions about privacy and commercial 
confidentiality are there, but perhaps solutions are arriving, 
and business people need to be practical.  Even an overpriced 
internal cloud gives much more power to internal entrepreneurs 
than did the old way.


Heh, a more centralized external cloud allows more agility than 
the centralized internal IT systems that were in place before?  
Perhaps.  Given all the data breaches, I don't think the problems 
with data security will ever go away though.

Voting for std.experimental.testing

2015-10-08 Thread Robert burner Schadek via Digitalmars-d-announce


http://forum.dlang.org/post/jnihyetudelpkvrxl...@forum.dlang.org

Re: Beta D 2.069.0-b1

2015-10-08 Thread Tourist via Digitalmars-d-announce


On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

First beta for the 2.069.0 release.

http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.069.0.html


Please report any bugs at https://issues.dlang.org

-Martin


The "libcurl is now loaded dynamically" link is broken.

Re: D and microservices

2015-10-08 Thread Laeeth Isharc via Digitalmars-d


On Wednesday, 7 October 2015 at 10:39:07 UTC, Russel Winder wrote:

On Tue, 2015-10-06 at 15:07 -0400, Nick Sabalausky via
(Kinda like how "cloud" sounds like a big fancy new revolution 
until you realize it's just the hip new word for "internet" or 
"hosted".


Yes - technically it is nothing new perhaps.  But it's a 
commercial phenomenon, and so whilst the marketing hype is 
regrettable, if inevitable, it's the commercial aspects that are 
important here, much more than technical ones.


Big technological shifts (speaking about things viewed from a 
societal level, not from a practitioner's perspective) have two 
components - big relative price shift (which might be infinite in 
practical terms to a large fortune or from cheap to very cheap 
depending on the situation), and then the new activities and new 
ways of doing old things that become possible as a consequence of 
this price shift.  Business people take a long time to figure it 
out (see Brynjolfsson's work on organisational architecture), and 
that's why we have a period of hand-wringing between the new 
technology arriving and us seeing its broader benefits.  Solow, 
an expert on growth, observed in 1987 that "computers are 
everywhere but in the productivity statistics".  (My theory then 
was that people were too busy fiddling with fonts on their Macs 
to actually do any work!). A decade later, we had a different 
view of their influence.  Similarly we have people saying today 
"how many jobs has Twitter created?".  But it's not the people 
that Twitter directly employ, but those that benefit both from 
using it, and from the broader set of shifts of which Twitter is 
only the beginning.  Blyth Masters, for example, is doing some 
interesting work on exploring possibilities from using blockchain 
type technologies for wholesale finance.  There are some obvious 
problems there, but I wouldn't care to bet nothing interesting 
comes out of it.  But it's much bigger than that, even though I 
can only be aware of a part of it.


In any case, we have now inconceivable amounts of computing power 
on tap for very affordable prices and the tools to manage it.  
When a little instance is 0.7 cents an hour, and a usable one is 
1.5 cents and you can scale up and down as quickly as you like, 
many things become possible that weren't before.  The world is 
only slowly beginning to figure out what, judging by what I see 
in finance.


"Cloud" is really a destruction of personal computing in favour 
of re- centralization of all computing: put the computing power 
back in the hands of the people who want to control what you 
may or may not do with computers. Beyond this is gets political.



Does that sound about accurate, or am I missing something?


Since I am foolish enough to run my own mail server, you can be 
sure that my sympathies are with you.  I think people are 
reckless - both individuals and corporations - in what they 
unthinkingly cede to companies that really have few incentives to 
act as one might wish.  It's one thing to be the customer, and 
quite another to be the product.  I saw Eric Schmidt speak some 
years back, and he really didn't give me a feeling that we have a 
similar idea about what evil means!


This being said, the world has always been broken in some 
respect, and we shouldn't let that stop us looking at the 
situation objectively even if one would wish in some respects 
things were other than they are.  The cloud may be centralising 
things for the individual, but at the corporate level it's less 
clear.  In particular, it's a classic case of the accounting 
being pretty clear that the economies of scale mean you should 
centralise IT infrastructure and it's management, but the 
practical experience of the people actually generating value 
within the enterprise often being rather different.  Things even 
in quite small firms of 150+ people start being more about 
internal bureaucratic logic and much less about ROI.  And the 
problem is that it's hard to make a convincing case for something 
that doesn't yet exist, and yet many big things have the tiniest 
beginnings.  So the current enterprise technology environment 
discourages those little experiments that drive real innovation, 
as well as getting in the way of larger projects.  The cloud, by 
commoditising compute, and making the price much more transparent 
then is a force for breaking down central structures that no 
longer serve their needs well.  When you can get whatever you 
need from Amazon today, waiting months and paying 10x more starts 
to seem a little stiff, and people start asking questions when 
before they had no choice but to grin and bear it.  Of course the 
questions about privacy and commercial confidentiality are there, 
but perhaps solutions are arriving, and business people need to 
be practical.  Even an overpriced internal cloud gives much more 
power to internal entrepreneurs than did the old way.


I think you are missing some aspects of why

Re: Voting for std.experimental.testing

2015-10-08 Thread Rikki Cattermole via Digitalmars-d


On 08/10/15 9:21 PM, Robert burner Schadek wrote:

This is the voting thread for inclusion of std.experimental.testing into
phobos.

PR: https://github.com/D-Programming-Language/phobos/pull/3207
Dub: http://code.dlang.org/packages/unit-threaded
Doc: See CyberShadow/DAutoTest for up-to-date documentation build
Formal Review Thread:
http://forum.dlang.org/post/stbdckpfsysjtppld...@forum.dlang.org
Previous Thread:
http://forum.dlang.org/post/uzocokshugchescba...@forum.dlang.org

Please respond to this post with a comment starting with a single
"Yes"/"No" and optional explanation after that. Criteria you are
expected to evaluate as part of "Yes":

- is this functionality needed in Phobos
- is basic design sound (some breaking changes are OK for
std.experimental but not full redesign)

As usual, anyone can vote, but opinions of Phobos developers hold more
value.

Voting ends in 2 weeks, on Oktober 22.


Yes, but:

There is no way that could conflict with serializers/vibe.d's 
definitions. Let alone ORM's.


+struct name
+{
+string value;
+}

std/experimental/testing/gen_ut_main_mixin.d
Why is it not package(std.experimental.testing) and more importantly not 
called internal? There is nothing there which the user should be touching.


Alright seriously?
+/**
+ * Generate green coloured output on POSIX systems
+ */
+string green(in string msg) @safe pure const
+{
+return escCode(Color.green) ~ msg ~ escCode(Color.cancel);
+}

Somebody fix please: https://github.com/robik/consoled
Irk I don't like it being done like this. I want it done right or not at 
all pretty much.


Further thought about UDA's especially those with high conflict 
potential. Perhaps they should instead be moved out into e.g. 
std.stdudas. That way it is not locked into e.g. testing while being 
reusable.

Re: Beta D 2.069.0-b1

2015-10-08 Thread Ilya Yaroshenko via Digitalmars-d-announce


On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

First beta for the 2.069.0 release.

http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.069.0.html


Please report any bugs at https://issues.dlang.org

-Martin


Thanks!

Please add the PR about allocators for the next beta
https://github.com/D-Programming-Language/phobos/pull/3684

-Ilya

Re: Moving back to .NET

2015-10-08 Thread Ola Fosheim Grøstad via Digitalmars-d

On Wednesday, 7 October 2015 at 05:36:15 UTC, Ola Fosheim Grøstad 
wrote:




1. Define the target, then you can figure out the features.
2. Solid non-gc memory management and ownership.
3. Clean up the type system.
4. Complete the language spec.
5. Clean up the syntax.


That's very vague. Unless you have concrete cases along with 
possible solutions, nobody can follow your "plan".



6. Extend support to critical platforms like WebAssembly/asm.js


I agree. Nim are doing a good job at that as far as I know.



I have some prototypes for my own use, but not sure what 
relevance that has? Pull requests would require decision making 
and policy changes, and be utterly pointless without it. 
Design/policy changes will have to start with the project 
leaders, that's the only way. End-users do not directly affect 
language features.


In D you can make a contribution as a user, but it has to be 
concrete and backed up by valid arguments. General statements and 
common places won't change anything.


Unlike Go and Rust, D has grown out of experience with 
programming in general, it's based on what worked in other 
languages and what didn't. Go and Rust address certain narrowly 
defined areas (Go more so than Rust I think). Given D's history 
there is, of course, some waste lying around (as is in any 
software after ~10 years) that has to be cleaned up and I would 
welcome any concrete, practical input from your side. Start with 
simple things first. Any hands-on help is welcome.

Re: Check template parameter whether it has "length"

2015-10-08 Thread John Colvin via Digitalmars-d-learn


On Thursday, 8 October 2015 at 09:29:30 UTC, tcak wrote:
I am "trying" to write a function that takes an array of items, 
and returns the length of longest item.


[code]
size_t maxLength(A)( const A[] listOfString ) if( __traits( 
hasMember, A, "length" ) )

{
return 0; // not implemented yet
}
[/code]

I tried it with

if( __traits( compiles, A.length ) )

as well. But compiler doesn't match it.

writeln("Max Length: ", maxLength( ["foo", "123456789"] ));

Compilers says it cannot deduce function from argument types ...

I do not want to check whether the type "A" is string, char[], 
etc. As long as it has length (please do not put me into 
ranges, library functions etc as much as possible), I want the 
function to accept it.


I'm 99% sure something like __traits(hasMember, int[], "length" ) 
should evaluate to true. Please file a bug at issues.dlang.org   
I notice it also doesn't work for "ptr".


The correct workaround:
__traits(compiles, A.init.length ));
or
__traits(compiles, listOfStrings.length ));

A.length doesn't work because length is not a static member, so 
it's only accessible from an instance.


The __traits(compiles, ...) solution is actually more general 
because it will work if .length is implemented via UFCS and 
opDispatch.


FYI:
If you want to check whether a statement will compile, as opposed 
to an expression, make a function/delegate out of it, e.g.:

__traits(compiles, { size_t n = A.init.length; });
to check that A has a member length that can be assigned to 
size_t.


P.S. always check std.traits for solutions all your static 
reflection problems, there's a lot of good stuff in there.

Re: D 2015/2016 Vision?


On Thursday, 8 October 2015 at 10:05:53 UTC, Kagamin wrote:

On Wednesday, 7 October 2015 at 00:17:37 UTC, bitwise wrote:
If it takes long enough that C++ has reflection, modules, 
ranges, stackless coroutines, concepts, etc, then I gotta be 
honest, I'm gonna start worrying about investing too much time 
in D.


You manage resources with reference counting in C++? How it 
deals with circular references?


You have to use weak pointers for back references.

http://en.cppreference.com/w/cpp/memory/weak_ptr

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 10:15:12 UTC, Ola Fosheim Grøstad 
wrote:

You have to use weak pointers for back references.

http://en.cppreference.com/w/cpp/memory/weak_ptr


I suspected as much and the next question is how is it better 
than C# solution except that one used to cope with C++ way?

Re: Moving back to .NET

On Thursday, 8 October 2015 at 09:45:53 UTC, Ola Fosheim Grøstad 
wrote:

On Thursday, 8 October 2015 at 09:24:50 UTC, Chris wrote:
On Wednesday, 7 October 2015 at 05:36:15 UTC, Ola Fosheim 
Grøstad wrote:



That's not vague at all.



1. Define the target, then you can figure out the features.


Then define the target. Make some suggestions.


2. Solid non-gc memory management and ownership.


Any specific implementation in mind?


3. Clean up the type system.


Examples + solutions?


4. Complete the language spec.


I thought that was the last thing we should do.


5. Clean up the syntax.


Examples + solutions?

You can put your proposals on Wiki.

Re: Voting for std.experimental.testing

2015-10-08 Thread Per Nordlöw via Digitalmars-d

On Thursday, 8 October 2015 at 08:21:58 UTC, Robert burner 
Schadek wrote:
This is the voting thread for inclusion of 
std.experimental.testing into phobos.

Voting ends in 2 weeks, on Oktober 22.


Sorry for being late with this but I added two comments in the PR:

One more important:

https://github.com/D-Programming-Language/phobos/pull/3207/files#r41494484

One less important:

https://github.com/D-Programming-Language/phobos/pull/3207/files#r41494229

Re: D 2015/2016 Vision?

2015-10-08 Thread Andrea Fontana via Digitalmars-d-announce


On Wednesday, 7 October 2015 at 00:17:37 UTC, bitwise wrote:
If it takes long enough that C++ has reflection, modules, 
ranges, stackless coroutines, concepts, etc, then I gotta be 
honest, I'm gonna start worrying about investing too much time 
in D.


You manage resources with reference counting in C++? How it deals 
with circular references?

Re: Threading Questions

2015-10-08 Thread Kagamin via Digitalmars-d-learn


On Thursday, 8 October 2015 at 02:31:24 UTC, bitwise wrote:
If you have System.Collections.Generic.List(T) static class 
member, there is nothing wrong with using it from multiple 
threads like this:


The equivalent of your D example would be

class Foo {
static List numbers = new List();
void bar() {
new Thread(()=>{
numbers.Add(1);
}).Start();
}
}

Re: Beta D 2.069.0-b1


On Thursday, 8 October 2015 at 09:17:16 UTC, Martin Nowak wrote:

On Thursday, 8 October 2015 at 04:53:53 UTC, Suliman wrote:

Is it DDMD based release?


Yes.


Are dmd 2.069b1 binaries compiled with dmd 2.069b1 or with dmd 
2.068.2?

[Issue 15176] [REG2.069.0-b1] ICE(glue.c):separate compilation with -inline crash in glue.c

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

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull
   Hardware|x86 |All
Summary|[REG2.069b1]|[REG2.069.0-b1]
   |ICE(glue.c):separate|ICE(glue.c):separate
   |compilation with -inline|compilation with -inline
   |crash in glue.c |crash in glue.c
 OS|Windows |All

--- Comment #2 from Kenji Hara  ---
https://github.com/D-Programming-Language/dmd/pull/5170

--

[Issue 7066] You can redefine .init and .stringof without error

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

--- Comment #8 from Sobirari Muhomori  ---
(In reply to timon.gehr from comment #6)
> It would be better to have a specific feature here though. E.g. 
> 
> struct S{ @disable init; }

struct S{ @disable void init(); } ?

--

[Issue 15178] New: "Try D" widget on homepage mangles Unicode

2015-10-08 Thread Ola Fosheim Grøstad via Digitalmars-d

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

  Issue ID: 15178
   Summary: "Try D" widget on homepage mangles Unicode
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: drthing...@msn.com

If I run this sample on the websites "Try D" widget:

// Sort lines
import std.stdio;
import std.array;
import std.algorithm;

void main()
{
stdin
.byLine(KeepTerminator.yes)
.map!(a => a.idup)
.array
.sort
.copy(stdout.lockingTextWriter());
}

with this data:

fish
こんにちは
学生
Pūkeko
salami
Tent
Patrick
Python

I get the following:

P\u016bkeko
Patrick
Python
Tent
\u3053\u3093\u306b\u3061\u306f
\u5b66\u751f
fish
salami

--

Re: Moving back to .NET


On Thursday, 8 October 2015 at 11:34:51 UTC, Chris wrote:
in D. Then again, I don't know how Go and Rust will fare in a 
couple of years' time.


I think the C++ people are desperately trying to recapture the 
application market with some of the things that they propose for 
C++17/20. I think that market is dying fast for C++. I don't know 
about Rust, they seem to aim for high level programming. I think 
both C++ and Rust have too many syntax issues to be convenient 
for high level applications.


Go I think will do ok for focused web services with not too 
complicated logic. I don't think they will replace Java. I think 
Go will take the market where people have been using Java, but 
not really needed the feature set.


The lines seem to blur over time, because any language is 
pretty useless without at least one powerful library to its 
name.


Applications benefit from frameworks, and then the desired 
frameworks dictate the language you use. So growth is difficult 
in that domain.


But you can implement you application model in an "engine 
language" and use a javascript framework for the UI with a 
browser engine in-between then the "engine language" can focus on 
efficient marshalling between that browser engine and the runtime.


So basically, break up the eco system so that you aren't locked 
into a small language (like D or Rust).

Re: Moving back to .NET

2015-10-08 Thread Ola Fosheim Grøstad via Digitalmars-d


On Thursday, 8 October 2015 at 09:24:50 UTC, Chris wrote:
On Wednesday, 7 October 2015 at 05:36:15 UTC, Ola Fosheim 
Grøstad wrote:




1. Define the target, then you can figure out the features.
2. Solid non-gc memory management and ownership.
3. Clean up the type system.
4. Complete the language spec.
5. Clean up the syntax.


That's very vague. Unless you have concrete cases along with 
possible solutions, nobody can follow your "plan".


That's not vague at all.

Re: Moving back to .NET

2015-10-08 Thread Ola Fosheim Grøstad via Digitalmars-d


On Thursday, 8 October 2015 at 10:31:57 UTC, Chris wrote:
On Thursday, 8 October 2015 at 09:45:53 UTC, Ola Fosheim 
Grøstad wrote:

That's not vague at all.



1. Define the target, then you can figure out the features.


Then define the target. Make some suggestions.


I've already raised this topic in a thread where I asked where D 
sits in the web space. And I did that because it has been said 
that vibe.d defines a key application area. However, that is a 
very hard market to capture which many expressed in that thread.


I think D could do well if it focused on engine-level system 
programming and made sure it was absolutely top notch for that 
purpose. (Game engines, search engines, ray tracing engines, in 
memory database engines, business logic engines, etc).


The current focus goes the other way. The current assumption is 
that engines are written in C/C++ and they are used to complete 
applications in D. That would make D an application level 
language, which makes success _very_difficult. As time progresses 
I believe it makes less and less sense to do a full application 
in languages like C/C++/Rust/D...


But if you create an "engine language" then you also need to be 
very good at exporting APIs. Like having compact and readable API 
definitions in D that lends itself to auto-generating interfaces 
for other languages (Python, Ruby, Go, Javascript etc).



2. Solid non-gc memory management and ownership.


Any specific implementation in mind?


Change the language enough so that you can do full pointer 
analysis and compete with Rust/C++.


Limit GC to actors.  Use move semantics between actors.

Point 3 and out really depends on what you do with point 1 and 2.

The key point here is that the project leadership needs to start 
with defining enough constraints to do rational focused and 
strategic decision making.


Then make a high level plan that takes you from where you are to 
a finished project, then you refine the plan (and evolve it).


Piling up proposals and endless non-breaking evolution isn't 
effective.

Re: Check template parameter whether it has "length"

2015-10-08 Thread Artur Skawina via Digitalmars-d-learn

On 10/08/15 11:29, tcak via Digitalmars-d-learn wrote:
> I am "trying" to write a function that takes an array of items, and returns 
> the length of longest item.
> 
> [code]
> size_t maxLength(A)( const A[] listOfString ) if( __traits( hasMember, A, 
> "length" ) )
> {
> return 0; // not implemented yet
> }
> [/code]
> 
> I tried it with
> 
> if( __traits( compiles, A.length ) )
> 
> as well. But compiler doesn't match it.

Use `A.init.length` instead of `A.length`.


You could also use something like

   if(is(typeof(A.init.length):size_t))


artur

Re: Is Anything Holding you back?

2015-10-08 Thread Ola Fosheim Grøstad via Digitalmars-d


On Wednesday, 7 October 2015 at 16:09:37 UTC, Jan Johansson wrote:

Yepp, that's the point of SOA :-) We are in agreement.


:) Since the contract is known upfront, it can be processed at 
compile time and D can do it. C# has to do it at run time because 
it can't do a thing at compile time.

Re: D 2015/2016 Vision?


On Thursday, 8 October 2015 at 11:31:49 UTC, Kagamin wrote:
cyclic graph. If you must manually verify the graph and put 
weak references appropriately - what kind of design in that?


It's a system programming language design... If you plan your 
model before coding it is rather easy to detect cycles in the 
model. Make the primary data structure a directed acyclic graph, 
then add back pointers as weak_ptr for secondary relations.


I believe you will find the same issues in Objective-C and Swift.

Other options:

- use regional allocation (free all resources at once)

- use a local scanner (trace live resources locally to a data 
structure, then free the ones that are not referenced).

Re: Voting for std.experimental.testing

2015-10-08 Thread Per Nordlöw via Digitalmars-d

On Thursday, 8 October 2015 at 08:52:04 UTC, Rikki Cattermole 
wrote:

Alright seriously?
+/**
+ * Generate green coloured output on POSIX systems
+ */
+string green(in string msg) @safe pure const
+{
+return escCode(Color.green) ~ msg ~ 
escCode(Color.cancel);

+}

Somebody fix please: https://github.com/robik/consoled
Irk I don't like it being done like this. I want it done right 
or not at all pretty much.


Further thought about UDA's especially those with high conflict 
potential. Perhaps they should instead be moved out into e.g. 
std.stdudas. That way it is not locked into e.g. testing while 
being reusable.


What about using compile-time-only struct-wrappers or UDA's for 
Visual attributes such as color, boldness, etc? For a showcase 
see my pretty.d (which I plan to propose to put in 
std.experimental.pretty):


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

It has bitrotten a bit lately but I'll fix it today if you want 
to have live showcase.

Re: Tell GC to use shared memory

2015-10-08 Thread Kagamin via Digitalmars-d-learn

GC is chosen at link time simply to satisfy unresolved symbols. 
You only need to compile your modified GC and link with it, it 
will be chosen instead of GC from druntime, no need to recompile 
anything else.

Re: D 2015/2016 Vision?

2015-10-08 Thread Ola Fosheim Grøstad via Digitalmars-d


On Thursday, 8 October 2015 at 10:26:22 UTC, Kagamin wrote:
On Thursday, 8 October 2015 at 10:15:12 UTC, Ola Fosheim 
Grøstad wrote:

You have to use weak pointers for back references.

http://en.cppreference.com/w/cpp/memory/weak_ptr


I suspected as much and the next question is how is it better 
than C# solution except that one used to cope with C++ way?


I don't know. I don't like extensive reference counting and don't 
use weak_ptr. One can usually avoid cycles for resources by 
design.

Re: Beta D 2.069.0-b1

2015-10-08 Thread Martin Nowak via Digitalmars-d-announce

On 10/08/2015 11:36 AM, lobo wrote:
> 
> Is there any info on the benchmarking between DDMD and DMD?

Still on the todo list to decide whether we need to use gdc to build ddmd.
https://trello.com/c/OT6jlFNa/85-rebench-ddmd-vs-dmd-compiler-speed

Re: D 2015/2016 Vision?

2015-10-08 Thread Ola Fosheim Grøstad via Digitalmars-d


On Wednesday, 7 October 2015 at 17:02:51 UTC, Paulo Pinto wrote:
On Wednesday, 7 October 2015 at 15:42:57 UTC, Ola Fosheim 
Grøstad wrote:

Are you thinking about Rust, or some other language?


All of the ones that explore this area. Rust, ATS, Idris, F*


Oh, yeah, sure. I wondered more if you were looking to adopt a 
language with substructural typing (beyond library types like 
unique_ptr) for production.


I personally think that they future is with actor-based 
programming in combination with substructural/behavioural typing 
since it lends itself to distributed computing, multi core etc. 
The challenge is making a good language for it that is 
sufficiently performant and still allows breaking out actors to 
other computational units (computers/CPUs).


But yeah, I think there is a paradigm shift coming in ~10-15 
years maybe?


Are you thinking about more lintish tools that can give false 
positives, or something with guarantees that can be a language 
feature?


What Herb Sutter demoed at CppCon as compiler validation to 
CoreC++.


I've only seen the talks on youtube. I was under the impression 
that Microsoft had accurate and inaccurate analysers, but that 
the accurate ones were too slow on current C++ code bases. With 
more annotations to guide the analyser... yes, maybe.


I assume Microsoft use analysers based on Boogie:

http://research.microsoft.com/en-us/projects/boogie/

I can imagine that depending on how well the community takes 
those guidelines, they might become part of C++20.


I think this is needed, but adoption probably won't happen 
without IDE benefits.

Re: Moving back to .NET

On Thursday, 8 October 2015 at 10:59:04 UTC, Ola Fosheim Grøstad 
wrote:

On Thursday, 8 October 2015 at 10:31:57 UTC, Chris wrote:
On Thursday, 8 October 2015 at 09:45:53 UTC, Ola Fosheim 
Grøstad wrote:

That's not vague at all.



1. Define the target, then you can figure out the features.


Then define the target. Make some suggestions.


I've already raised this topic in a thread where I asked where 
D sits in the web space. And I did that because it has been 
said that vibe.d defines a key application area. However, that 
is a very hard market to capture which many expressed in that 
thread.


I think D could do well if it focused on engine-level system 
programming and made sure it was absolutely top notch for that 
purpose. (Game engines, search engines, ray tracing engines, in 
memory database engines, business logic engines, etc).


The current focus goes the other way. The current assumption is 
that engines are written in C/C++ and they are used to complete 
applications in D. That would make D an application level 
language, which makes success _very_difficult. As time 
progresses I believe it makes less and less sense to do a full 
application in languages like C/C++/Rust/D...


I agree that D should be strong in this area (engine level). On 
top of that you can stack powerful libs like Phobos. I use D as 
an engine in some projects and I'm thinking of using it for this 
purpose in other projects further down the road, for example 
using D as an engine for simpler, high-level languages like 
linguistic analysis tools where rules are defined by 
non-programmers at a higher level.


But by no means is it necessary that D be confined to this 
particular use case. An "engine language" can be extended with 
libs. However, you have to draw a clear line between the standard 
library and the language. This border is a bit blurred in D. Then 
again, I don't know how Go and Rust will fare in a couple of 
years' time. The lines seem to blur over time, because any 
language is pretty useless without at least one powerful library 
to its name.


But if you create an "engine language" then you also need to be 
very good at exporting APIs. Like having compact and readable 
API definitions in D that lends itself to auto-generating 
interfaces for other languages (Python, Ruby, Go, Javascript 
etc).

Re: D 2015/2016 Vision?

2015-10-08 Thread Nicholas Wilson via Digitalmars-d-learn

On Thursday, 8 October 2015 at 10:34:44 UTC, Ola Fosheim Grøstad 
wrote:
I don't know. I don't like extensive reference counting and 
don't use weak_ptr. One can usually avoid cycles for resources 
by design.


The required design is that a resource handle must reside in a 
non-resource object, that object must be reference counted too to 
ensure correctness of resource management, and you can't 
guarantee reliably that those non-resource objects don't form a 
cyclic graph. If you must manually verify the graph and put weak 
references appropriately - what kind of design in that?

Re: Check template parameter whether it has "length"


On Thursday, 8 October 2015 at 09:29:30 UTC, tcak wrote:
I am "trying" to write a function that takes an array of items, 
and returns the length of longest item.


[code]
size_t maxLength(A)( const A[] listOfString ) if( __traits( 
hasMember, A, "length" ) )

{
return 0; // not implemented yet
}
[/code]

I tried it with

if( __traits( compiles, A.length ) )

as well. But compiler doesn't match it.

writeln("Max Length: ", maxLength( ["foo", "123456789"] ));

Compilers says it cannot deduce function from argument types ...

I do not want to check whether the type "A" is string, char[], 
etc. As long as it has length (please do not put me into 
ranges, library functions etc as much as possible), I want the 
function to accept it.


iirc there's a hasLength trait in std.traits e.g. static 
assert(hasLength!int[])

[Issue 7066] You can redefine .init and .stringof without error

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

Sobirari Muhomori  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=14237

--

[Issue 14237] Compiler should reject attempts to (re)define .init

2015-10-08 Thread Per Nordlöw via Digitalmars-d-announce

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

Sobirari Muhomori  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=7066

--

Re: Shout out to D at cppcon, when talkign about ranges.

2015-10-08 Thread John Colvin via Digitalmars-d


On Thursday, 8 October 2015 at 12:35:08 UTC, Kagamin wrote:


Hmm... conceptually a bidirectional range should be able to 
iterate back and forth:


void is_word_boundary(Bidi r)
{
bool is_word_prev = r.re.empty ? false : isword(r.re.back);
bool is_word_this = r.empty ? false : isword(r.front);
return is_word_prev != is_word_this;
}

auto i = myrange;
for(; !i.empty; i.popFront())
if( is_word_boundary(i) )
break;


On Thursday, 8 October 2015 at 12:53:24 UTC, Kagamin wrote:
The backward range can have an input range interface, like 
retro:


void is_word_boundary(Bidi r)
{
bool is_word_prev = r.prev.empty ? false : 
isword(r.prev.front);

bool is_word_this = r.empty ? false : isword(r.front);
return is_word_prev != is_word_this;
}


What you're effectively describing is a trio of iterators wrapped 
to give an interface of two linked ranges. popFront grows the 
first one and shrinks the second. I'd be interested to see how to 
construct that, given a generic range as input.

Re: Beta D 2.069.0-b1


On Thursday, 8 October 2015 at 09:36:31 UTC, lobo wrote:
PS: Big thanks for the much improved release process that you 
guys are maintaining.


I agree. Thank you, Martin.

Re: Voting for std.experimental.testing

2015-10-08 Thread Rikki Cattermole via Digitalmars-d


On 09/10/15 1:12 AM, Per Nordlöw wrote:

On Thursday, 8 October 2015 at 08:52:04 UTC, Rikki Cattermole wrote:

Alright seriously?
+/**
+ * Generate green coloured output on POSIX systems
+ */
+string green(in string msg) @safe pure const
+{
+return escCode(Color.green) ~ msg ~ escCode(Color.cancel);
+}

Somebody fix please: https://github.com/robik/consoled
Irk I don't like it being done like this. I want it done right or not
at all pretty much.

Further thought about UDA's especially those with high conflict
potential. Perhaps they should instead be moved out into e.g.
std.stdudas. That way it is not locked into e.g. testing while being
reusable.


What about using compile-time-only struct-wrappers or UDA's for Visual
attributes such as color, boldness, etc? For a showcase see my pretty.d
(which I plan to propose to put in std.experimental.pretty):

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

It has bitrotten a bit lately but I'll fix it today if you want to have
live showcase.


I don't terribly care about that :) I just hate seeing something that we 
should have being done privately and in Phobos.

Re: Moving back to .NET

On Thursday, 8 October 2015 at 11:56:58 UTC, Ola Fosheim Grøstad 
wrote:

On Thursday, 8 October 2015 at 11:34:51 UTC, Chris wrote:
in D. Then again, I don't know how Go and Rust will fare in a 
couple of years' time.


I think the C++ people are desperately trying to recapture the 
application market with some of the things that they propose 
for C++17/20. I think that market is dying fast for C++. I 
don't know about Rust, they seem to aim for high level 
programming. I think both C++ and Rust have too many syntax 
issues to be convenient for high level applications.


Go I think will do ok for focused web services with not too 
complicated logic. I don't think they will replace Java. I 
think Go will take the market where people have been using 
Java, but not really needed the feature set.


But a language like D that is already very feature rich cannot be 
dragged down to the level of Go anymore. D combines Go and Java, 
although in an incomplete way (as of now).


The lines seem to blur over time, because any language is 
pretty useless without at least one powerful library to its 
name.


Applications benefit from frameworks, and then the desired 
frameworks dictate the language you use. So growth is difficult 
in that domain.


But you can implement you application model in an "engine 
language" and use a javascript framework for the UI with a 
browser engine in-between then the "engine language" can focus 
on efficient marshalling between that browser engine and the 
runtime.


So basically, break up the eco system so that you aren't locked 
into a small language (like D or Rust).


That's what I've been doing for 2-3 years now thanks to D. I use 
D as the core and everything else is glued onto the D core. D is 
actually pretty good at this. Since it's cross-platform, I can 
use the same code base everywhere. I don't need to worry about 
UIs or the like. On Windows, for example, I can compile the code 
into a dll and expose the functions that are needed. The UI can 
be in Python, Lua or whatever. I'm kinda using D as "C with 
high-level features". This is exactly what brought me to D, not 
having to worry about platforms anymore. Write once, connect to 
anything.

Re: D 2015/2016 Vision?

2015-10-08 Thread Paulo Pinto via Digitalmars-d

On Thursday, 8 October 2015 at 11:15:35 UTC, Ola Fosheim Grøstad
wrote:

On Wednesday, 7 October 2015 at 17:02:51 UTC, Paulo Pinto wrote:
On Wednesday, 7 October 2015 at 15:42:57 UTC, Ola Fosheim
Grøstad wrote:

Are you thinking about Rust, or some other language?

All of the ones that explore this area. Rust, ATS, Idris,
F*

Oh, yeah, sure. I wondered more if you were looking to adopt a
language with substructural typing (beyond library types like
unique_ptr) for production.

Not a chance.

In my little universe it is all about JVM and .NET languages,
JavaScript for the browser and C++ for when there isn't any other
way.

Those languages is where I am having fun now, besides mobile
coding. But it is

just dabbling and reading papers about them, nothing serious.

It is really hard to keep up with JVM, .NET and occasional look
into C++. The languages are easy when compared to the whole
ecosystem, hence why I went silent.

Just decided to comment, as an explanation of what resource
management is possible in modern versions of Java/.NET.

I personally think that they future is with actor-based
programming in combination with substructural/behavioural
typing since it lends itself to distributed computing, multi
core etc. The challenge is making a good language for it that
is sufficiently performant and still allows breaking out actors
to other computational units (computers/CPUs).

Microsoft Research had an actor-based language for awhile, Axum.

Many of the ideas are now in .NET.
http://blogs.msdn.com/b/maestroteam/archive/2011/02/28/the-state-of-axum.aspx

https://en.wikipedia.org/wiki/Axum_%28programming_language%29

http://download.microsoft.com/download/B/D/5/BD51FFB2-C777-43B0-AC24-BDE3C88E231F/Axum%20Programmers%20Guide.pdf

But yeah, I think there is a paradigm shift coming in ~10-15
years maybe?

Substructural typing for sure as it is coming slowly mainstream
now.

Several years ago it was just Agda, now there are several
projects, including

companies like Microsoft looking at it.

Are you thinking about more lintish tools that can give false
positives, or something with guarantees that can be a
language feature?

What Herb Sutter demoed at CppCon as compiler validation to
CoreC++.

I've only seen the talks on youtube. I was under the impression
that Microsoft had accurate and inaccurate analysers, but that
the accurate ones were too slow on current C++ code bases. With
more annotations to guide the analyser... yes, maybe.

I assume Microsoft use analysers based on Boogie:

http://research.microsoft.com/en-us/projects/boogie/

They use it on their driver validation tools.

I can imagine that depending on how well the community takes
those guidelines, they might become part of C++20.

I think this is needed, but adoption probably won't happen
without IDE benefits.

Yep, but for all of us that aren't shaving off ms or squeezing
one more byte into the cache line, it doesn't matter much.

--
Paulo

Re: Voting for std.experimental.testing

2015-10-08 Thread Atila Neves via Digitalmars-d

On Thursday, 8 October 2015 at 08:52:04 UTC, Rikki Cattermole 
wrote:

On 08/10/15 9:21 PM, Robert burner Schadek wrote:

[...]


Yes, but:

There is no way that could conflict with serializers/vibe.d's 
definitions. Let alone ORM's.


?



std/experimental/testing/gen_ut_main_mixin.d
Why is it not package(std.experimental.testing) and more 
importantly not called internal? There is nothing there which 
the user should be touching.


This is supposed to be used by the user.



Alright seriously?
+/**
+ * Generate green coloured output on POSIX systems
+ */
+string green(in string msg) @safe pure const
+{
+return escCode(Color.green) ~ msg ~ 
escCode(Color.cancel);

+}

Somebody fix please: https://github.com/robik/consoled


Get it into Phobos and I'll gladly use it.

Further thought about UDA's especially those with high conflict 
potential. Perhaps they should instead be moved out into e.g. 
std.stdudas. That way it is not locked into e.g. testing while 
being reusable.


If there's a conflict, that's what the package/module system is 
for:


@std.experimental.testing.name unittest { ... }

Atila

Re: D 2015/2016 Vision?

2015-10-08 Thread Jonathan M Davis via Digitalmars-d


On Thursday, 8 October 2015 at 08:21:09 UTC, Kagamin wrote:
On Tuesday, 6 October 2015 at 20:31:58 UTC, Jonathan M Davis 
wrote:
I don't think the problem is with structs. The problem is that 
programmers coming from other languages default to using 
classes. The default in D should always be a struct. You use a 
class because you actually need inheritance or because you 
want to ensure that a type is always a reference type and 
don't want to go to the trouble of writing a struct that way 
(and even then, you should probably just write the struct that 
way).


Hmm... If we must emulate reference semantics manually, it 
feels like C++ with explicit references, pointers and all sorts 
of smart pointers, and obviates need for classes being 
reference types: just emulate reference semantics as we must do 
it anyway.


Maybe, but having classes be value generally makes no sense, 
because you can't use polymorphism with value types. Classes are 
inherently reference types given their semantics. Even in C++ 
that's the case. It's just that they don't separate out classes 
and structs the way we do. But classes that use inheritance have 
to be used as reference types or all you're doing is sharing 
implementation (which can be done easily enough without 
inheritance). You're not doing anything with polymorphism without 
references. So, the separation that D has makes a lot of sense. 
It's just that in some cases - namely where determinstic 
destruction is required - having them be managed by the GC 
doesn't work, and we need a solution for that. Most classes work 
just fine with a garbage collector though.


And if we have classes that are inherently ref-counted or which 
are sitting inside of smart-pointers, then they're still 
reference types like they should be. They just have their 
lifetime managed in a more deterministic manner for those cases 
where that's appropriate.


- Jonathan M Davis

[Issue 15167] [REG2.069-devel] conflicting error with repeated alias declaration

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

--- Comment #5 from Kenji Hara  ---
(In reply to Kenji Hara from comment #3)
> Because today, two different alias declarations aliasing an identical type
> are allowed if they're accessed beyond the import boundaries.

Identical symbol aliases are also allowed via imports. So, I think the
following case would also need to be supported.

int a15167;
alias Var15167 = a15167;
alias Var15167 = a15167;

void f15167() {}
alias Foo15167 = f15167;
alias Func15167 = Foo15167;
alias Func15167 = f15167;

--

Re: Shout out to D at cppcon, when talkign about ranges.


The backward range can have an input range interface, like retro:

void is_word_boundary(Bidi r)
{
bool is_word_prev = r.prev.empty ? false : 
isword(r.prev.front);

bool is_word_this = r.empty ? false : isword(r.front);
return is_word_prev != is_word_this;
}

Re: Threading Questions

2015-10-08 Thread bitwise via Digitalmars-d-learn


On Thursday, 8 October 2015 at 10:11:38 UTC, Kagamin wrote:

On Thursday, 8 October 2015 at 02:31:24 UTC, bitwise wrote:
If you have System.Collections.Generic.List(T) static class 
member, there is nothing wrong with using it from multiple 
threads like this:


The equivalent of your D example would be

class Foo {
static List numbers = new List();
void bar() {
new Thread(()=>{
numbers.Add(1);
}).Start();
}
}


That still doesn't explain what you mean about it being illegal 
in other languages or why you brought up C# in the first place.


 Bit

Re: Shout out to D at cppcon, when talkign about ranges.

2015-10-08 Thread Steven Schveighoffer via Digitalmars-d-learn


On Wednesday, 7 October 2015 at 14:59:28 UTC, Trass3r wrote:
On Tuesday, 6 October 2015 at 22:39:01 UTC, Ulrich Küttler 
wrote:
Yes, this is an explanation. Thanks. So the argument being C++ 
customs. Now that you mention it, this seems to be the 
argument in Eric's D4128 paper, too.


I was hoping for a somewhat deeper reasoning. Out of 
curiously, I am still trying to grasp all the implications. 
Ranges are hard.


Another one is "odd number of iterators algorithms"

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4128.html#appendix-3-d-ranges-and-algorithmic-complexity
D’s choice of algorithmic basis operations is inherently less 
efficient than C++’s.


Hmm... conceptually a bidirectional range should be able to 
iterate back and forth:


void is_word_boundary(Bidi r)
{
bool is_word_prev = r.re.empty ? false : isword(r.re.back);
bool is_word_this = r.empty ? false : isword(r.front);
return is_word_prev != is_word_this;
}

auto i = myrange;
for(; !i.empty; i.popFront())
if( is_word_boundary(i) )
break;

Re: Bug? 0 is less than -10


On 10/7/15 1:27 AM, Laeeth Isharc wrote:

On Wednesday, 7 October 2015 at 02:53:32 UTC, Steven Schveighoffer wrote:

On 10/6/15 7:21 PM, Laeeth Isharc wrote:

could we have ssize_t defined in phobos somewhere so your code ends up
being portable ;) (It's trivial to do, obviously).


ptrdiff_t



It seems unnatural to use such a name when the variable has nothing to
do with pointers - it doesn't contribute to the readability.  Yes, it's
trivial, but small things cumulatively matter.  Adam tends to use int
and when that gets mixed up with an auto size_t (eg via length) then his
code doesn't compile on 64 bit.  And if it happens with his code, you
can imagine this isn't a problem that inexperienced users never encounter.


ptrdiff_t is in the C spec, ssize_t is not. No reason to name all the 
types of snow here.


A machine-word-sized signed integer is ptrdiff_t.

-Steve

Re: D 2015/2016 Vision?

2015-10-08 Thread Jonathan M Davis via Digitalmars-d

On Thursday, 8 October 2015 at 12:10:24 UTC, Ola Fosheim Grøstad 
wrote:

On Thursday, 8 October 2015 at 11:31:49 UTC, Kagamin wrote:
cyclic graph. If you must manually verify the graph and put 
weak references appropriately - what kind of design in that?


It's a system programming language design... If you plan your 
model before coding it is rather easy to detect cycles in the 
model. Make the primary data structure a directed acyclic 
graph, then add back pointers as weak_ptr for secondary 
relations.


I've programmed extensively in C++ with smart pointers, and in my 
experience, circular references are rarely a problem. There are 
some cases where it's obvious that you have one (e.g. where one 
object owns another and they need to talk to each other), in 
which case you either use a normal pointer or a weak reference, 
depending on which makes more sense. And in the cases that you 
don't catch, you find them in testing, figure out what should be 
a weak reference to get rid of the circular dependency, you fix 
it, and you move on. It really isn't a big deal in general, 
though I suppose that there could be certain ways of designing 
programs where it would be more problematic.


One advantage of using smart pointers with a GC is that the GC 
can then clean up circular references, and you don't necessarily 
even need weak pointers (though there are bound to be cases where 
they'd still be desirable). But the GC isn't required to solve 
the problem. It just makes it so that if you do end up with a 
circular reference problem, it'll fix itself.


- Jonathan M Davis

Re: Beta D 2.069.0-b1

2015-10-08 Thread Adam D. Ruppe via Digitalmars-d-announce


On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote:

Does that mean @property has no effect anymore ?


@property never actually worked anyway. It is still my hope that 
it will be correctly implemented some day though - the hard 
problem it was meant to solve is still there (returning delegates 
from properties, the other things are all minor stylistic things, 
but this is outright breakage).

Re: Moving back to .NET

2015-10-08 Thread Ola Fosheim Grøstad via Digitalmars-d


On Thursday, 8 October 2015 at 13:15:18 UTC, Chris wrote:
That's what I've been doing for 2-3 years now thanks to D. I 
use D as the core and everything else is glued onto the D core. 
D is actually pretty good at this. Since it's cross-platform, I 
can use the same code base everywhere. I don't need to worry 
about UIs or the like.


Yes, I think this is the more scalable approach for both D, C++ 
and Rust.


For my use case (virtual world simulation) I'll probably end up 
using the first production level language that can provide tight 
asm.js codege, IEEE754-2008 support and guarantee reproducible 
results between client and server. But maybe I'll end up having 
to using a JIT on the server... I don't think there are any 
obvious alternatives at the moment. Maybe Rust will get there 
first.

Re: Moving back to .NET

2015-10-08 Thread Ola Fosheim Grøstad via Digitalmars-d

On Thursday, 8 October 2015 at 13:45:43 UTC, Ola Fosheim Grøstad 
wrote:

On Thursday, 8 October 2015 at 13:15:18 UTC, Chris wrote:
That's what I've been doing for 2-3 years now thanks to D. I 
use D as the core and everything else is glued onto the D 
core. D is actually pretty good at this. Since it's 
cross-platform, I can use the same code base everywhere. I 
don't need to worry about UIs or the like.


Yes, I think this is the more scalable approach for both D, C++ 
and Rust.


For my use case (virtual world simulation) I'll probably end up 
using the first production level language that can provide 
tight asm.js codege, IEEE754-2008 support and guarantee 
reproducible results between client and server. But maybe I'll 
end up having to using a JIT on the server... I don't think 
there are any obvious alternatives at the moment. Maybe Rust 
will get there first.


It'd be nice to have asm.js or even JS.

Re: D 2015/2016 Vision?


On Thursday, 8 October 2015 at 13:20:51 UTC, Paulo Pinto wrote:
It is really hard to keep up with JVM, .NET and occasional look 
into C++. The languages are easy when compared to the whole 
ecosystem, hence why I went silent.


I've found getting a good understanding of C++11/14 to be a 
serious time sink, and that's just the language and standard 
library, which is pretty small. So I can understand those who 
just stick to a conservative C++ subset.


Just decided to comment, as an explanation of what resource 
management is possible in modern versions of Java/.NET.


Thanks :-)

Re: Shout out to D at cppcon, when talkign about ranges.

2015-10-08 Thread John Colvin via Digitalmars-d


On Thursday, 8 October 2015 at 14:36:03 UTC, Kagamin wrote:

On Thursday, 8 October 2015 at 13:10:24 UTC, John Colvin wrote:
What you're effectively describing is a trio of iterators 
wrapped to give an interface of two linked ranges. popFront 
grows the first one and shrinks the second. I'd be interested 
to see how to construct that, given a generic range as input.


The C++ example doesn't work with generic iterators, it needs a 
specific ability to iterate in both directions, hence a 
bidirectional range.


Of course.

The way ranges are used for iteration, they can be seen as 
adapters for iterators providing various consistent interfaces 
depending on their capabilities. In this example we need a 
bidirectional range that can go back and forth, one way to do 
it is to provide undo mechanism like undoPopFront and 
frontUndoEmpty to allow the range grow back, thus remaining a 
range that is a list of items and not an iterator.


I much prefer this second version:

Another way is to provide a reverse range of previously popped 
items - this can be seen as iterator or not, more like a range 
with history rather than an undoable input range, so maybe the 
getter should be `history`.


my question is: How, in practice, does one take a bidirectional 
range and make one of these new things? I foresee some 
difficulty, but perhaps I'm just not being imaginative enough.

Re: Beta D 2.069.0-b1

2015-10-08 Thread Jack Stouffer via Digitalmars-d-announce


On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

First beta for the 2.069.0 release.

http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.069.0.html


Please report any bugs at https://issues.dlang.org

-Martin


I think it should be mentioned in the change log the substantial 
improvements that were made to the docs since last release. After 
over 30 PRs were merged for improving the docs, they are WAY 
better than the 2.068 docs.

Re: Beta D 2.069.0-b1

2015-10-08 Thread Martin Nowak via Digitalmars-d-announce


On Thursday, 8 October 2015 at 12:20:23 UTC, Andrea Fontana wrote:
Are dmd 2.069b1 binaries compiled with dmd 2.069b1 or with dmd 
2.068.2?


The last released compiler, we don't have any bootstrap method 
(using a small C++ compiler or so).

Re: D 2015/2016 Vision?

2015-10-08 Thread Ola Fosheim Grøstad via Digitalmars-d

On Thursday, 8 October 2015 at 14:13:30 UTC, Jonathan M Davis 
wrote:
One advantage of using smart pointers with a GC is that the GC 
can then clean up circular references, and you don't 
necessarily even need weak pointers (though there are bound to 
be cases where they'd still be desirable). But the GC isn't 
required to solve the problem. It just makes it so that if you 
do end up with a circular reference problem, it'll fix itself.


Yes, in general ownership should not be circular at all. It 
should be a DAG growing from the current actor/process/stack in 
an unbroken chain of ownership-references.


This should not be conflated with references on the GC heap. In a 
pure object oriented GC world objects are created and never cease 
to exist, but when they are no longer reachable the computer can 
recycle the technical address (but not the conceptual identity). 
Conceptually automatic garbage collection (like mark/sweep) can 
be viewed as a memory optimization for our non-ideal computers 
that would not be needed on a turing machine where you have an 
endless amount of memory.


So I don't think there are _good_ reasons to call 
finalizers/destructors on the GC heap, it's a sign of a bad model 
where the responsibilities are unclear. GC objects should only 
"own" memory on the GC heap.


Example:

An initial GC file object should just represent the resource 
identity (URI/filepath), and the open/close actions should be 
handled by ownership tracking references rooted in the 
actors/processes that actually are responsible for accessing it.


I think the viewpoint that ownership is rooted in actors and not 
in objects is a better and more performant view than the 
"finalizer" view. However if the system allows actors to become 
unreachable the runtime might need a collection cycle for the 
actors themselves...

Re: Check template parameter whether it has "length"

2015-10-08 Thread tcak via Digitalmars-d-learn


On Thursday, 8 October 2015 at 09:50:12 UTC, John Colvin wrote:

On Thursday, 8 October 2015 at 09:29:30 UTC, tcak wrote:

[...]


I'm 99% sure something like __traits(hasMember, int[], "length" 
) should evaluate to true. Please file a bug at 
issues.dlang.org   I notice it also doesn't work for "ptr".


The correct workaround:
__traits(compiles, A.init.length ));
or
__traits(compiles, listOfStrings.length ));

A.length doesn't work because length is not a static member, so 
it's only accessible from an instance.


The __traits(compiles, ...) solution is actually more general 
because it will work if .length is implemented via UFCS and 
opDispatch.


FYI:
If you want to check whether a statement will compile, as 
opposed to an expression, make a function/delegate out of it, 
e.g.:

__traits(compiles, { size_t n = A.init.length; });
to check that A has a member length that can be assigned to 
size_t.


P.S. always check std.traits for solutions all your static 
reflection problems, there's a lot of good stuff in there.


__traits(compiles, { size_t n = A.init.length; });  did the trick.

[code]
size_t maxLength(A)( const A[] listOfString )
if( __traits( compiles, { size_t len = A.init.length; } ) )
{
size_t len = 0;

foreach(A str; listOfString)
if( str.length > len ) len = str.length;

return len;
}
[/code]

BTW, there is nothing like std.traits.hasLength.

Re: Check template parameter whether it has "length"

2015-10-08 Thread John Colvin via Digitalmars-d-learn


On Thursday, 8 October 2015 at 15:22:02 UTC, tcak wrote:

BTW, there is nothing like std.traits.hasLength.


yeah, that's because __traits(hasMember, ...) should be good 
enough, but obviously not in this case at the moment.

Re: Shout out to D at cppcon, when talkign about ranges.

2015-10-08 Thread Martin Nowak via Digitalmars-d-announce


On Thursday, 8 October 2015 at 13:10:24 UTC, John Colvin wrote:
What you're effectively describing is a trio of iterators 
wrapped to give an interface of two linked ranges. popFront 
grows the first one and shrinks the second. I'd be interested 
to see how to construct that, given a generic range as input.


The C++ example doesn't work with generic iterators, it needs a 
specific ability to iterate in both directions, hence a 
bidirectional range.


The way ranges are used for iteration, they can be seen as 
adapters for iterators providing various consistent interfaces 
depending on their capabilities. In this example we need a 
bidirectional range that can go back and forth, one way to do it 
is to provide undo mechanism like undoPopFront and frontUndoEmpty 
to allow the range grow back, thus remaining a range that is a 
list of items and not an iterator. Another way is to provide a 
reverse range of previously popped items - this can be seen as 
iterator or not, more like a range with history rather than an 
undoable input range, so maybe the getter should be `history`.

Re: Beta D 2.069.0-b1


On Thursday, 8 October 2015 at 14:59:15 UTC, Jack Stouffer wrote:
I think it should be mentioned in the change log the 
substantial improvements that were made to the docs since last 
release. After over 30 PRs were merged for improving the docs, 
they are WAY better than the 2.068 docs.


Sure, just add it to the changelog.
https://github.com/D-Programming-Language/dlang.org/pull/1118

Re: Beta D 2.069.0-b1

2015-10-08 Thread David Nadlinger via Digitalmars-d-announce


On Thursday, 8 October 2015 at 15:01:31 UTC, Martin Nowak wrote:
On Thursday, 8 October 2015 at 12:20:23 UTC, Andrea Fontana 
wrote:
Are dmd 2.069b1 binaries compiled with dmd 2.069b1 or with dmd 
2.068.2?


The last released compiler, we don't have any bootstrap method 
(using a small C++ compiler or so).


One does not exclude the other. You could still re-build 2.069b1 
using itself.


 — David

Re: Beta D 2.069.0-b1

2015-10-08 Thread anonymous via Digitalmars-d-announce

On Thursday 08 October 2015 06:14, extrawurst wrote:

> `The -property switch has been deprecated.` Does that mean 
> @property has no effect anymore ?

Yes. I've made a pull request to mention that (and put a note on the spec 
page).

https://github.com/D-Programming-Language/dlang.org/pull/1119

We should probably try to finally find good semantics for @property.

Re: Beta D 2.069.0-b1

2015-10-08 Thread Martin Nowak via Digitalmars-d-announce


On Thursday, 8 October 2015 at 12:48:48 UTC, Adam D. Ruppe wrote:

On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote:

Does that mean @property has no effect anymore ?


@property never actually worked anyway. It is still my hope 
that it will be correctly implemented some day though


I think http://wiki.dlang.org/DIP23 reflects the most accurate 
roadmap for @property, basically being permissive w.r.t. parens. 
And who really cares whether it's rng.popFront or rng.popFront()?

[Issue 15177] mixin + traits issue with 2.069 beta 1

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu
   Severity|enhancement |regression

--

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 15:30:17 UTC, Jonathan M Davis 
wrote:

On Wednesday, 7 October 2015 at 12:59:05 UTC, bitwise wrote:
On Wednesday, 7 October 2015 at 09:49:27 UTC, Marc Schütz 
wrote:
RefCounted isn't implemented for classes, but there's no 
reason why it shouldn't work.



Really, I don't get why everyone wants to have builtin 
refcounting, when all that's required is a working way to 
make escape-proof references.


If you make a class that owns a resources that needs 
deterministic destruction, there is no guarantee that everyone 
will wrap that class in a RefCounted properly. Also, I've 
already stated many more problems with struct wrappers.


Except it doesn't even matter if they always wrap it properly - 
or even if something like DIP 74 is implemented. The core 
problem is that no object (be it struct or class) which needs 
deterministic destruction can have its lifetime managed by the 
GC - be it be simply being directly allocated by the GC or by 
sitting inside of an object that was put on the GC heap without 
any kind of ref-counting.


With DIP74, the ref counting is hard coded into the type itself. 
The intention of the original author of the class is inseparable 
from the code. The same is not true for a class that is simply 
"meant" to be used in a context where it has deterministic 
destruction.


So if I was a graphics programmer, and awake of this 
issue(deterministic destruction), I could open up a class and 
just look for opRelease() rather than having to try and reason 
about it's usage.



The programmer is always going to have to be careful about 
where they put an object that needs deterministic destruction.


Again, it's much easier to be careful about this when the 
author's intent is baked into the class.



Regardless of the ref-counting mechanism though, you can't 
guarantee that it's going to be used correctly. The best that 
we can do is guarantee that if it is used correctly, then the 
object will be destroyed deterministically.


Since you're probably going to make me repeat myself anyways, I 
might as well get it out of the way ;)


Again, it's much easier to be careful about this when the 
author's intent is baked into the class.


 Bit

Re: Go, D, and the GC

2015-10-08 Thread Marco Leise via Digitalmars-d

Am Mon, 05 Oct 2015 13:42:50 +
schrieb Adam D. Ruppe :

> On Monday, 5 October 2015 at 07:40:35 UTC, deadalnix wrote:
> > Not on the heap. There are many cases where the destructor 
> > won't run and it is allowed by spec. We should do better.
> 
> To be fair, if you new a struct in C++ and never delete it, the 
> destructor will never run there either. D's in the same boat in 
> that regard.

But the D boat reads "Garbage Collector". And besides, D now
runs dtors on new'd structs. The "many cases" may be different
ones than you imagine.

-- 
Marco

Re: Shout out to D at cppcon, when talkign about ranges.

2015-10-08 Thread H. S. Teoh via Digitalmars-d

On Thu, Oct 08, 2015 at 02:46:05PM +, John Colvin via Digitalmars-d wrote:
> On Thursday, 8 October 2015 at 14:36:03 UTC, Kagamin wrote:
> >On Thursday, 8 October 2015 at 13:10:24 UTC, John Colvin wrote:
> >>What you're effectively describing is a trio of iterators wrapped to
> >>give an interface of two linked ranges. popFront grows the first one
> >>and shrinks the second. I'd be interested to see how to construct
> >>that, given a generic range as input.
> >
> >The C++ example doesn't work with generic iterators, it needs a
> >specific ability to iterate in both directions, hence a bidirectional
> >range.
> 
> Of course.
> 
> >The way ranges are used for iteration, they can be seen as adapters
> >for iterators providing various consistent interfaces depending on
> >their capabilities. In this example we need a bidirectional range
> >that can go back and forth, one way to do it is to provide undo
> >mechanism like undoPopFront and frontUndoEmpty to allow the range
> >grow back, thus remaining a range that is a list of items and not an
> >iterator.
> 
> I much prefer this second version:
> 
> >Another way is to provide a reverse range of previously popped items
> >- this can be seen as iterator or not, more like a range with history
> >rather than an undoable input range, so maybe the getter should be
> >`history`.
> 
> my question is: How, in practice, does one take a bidirectional range
> and make one of these new things? I foresee some difficulty, but
> perhaps I'm just not being imaginative enough.

Bidirectional ranges do have a fundamental lack in their definition, in
that the bidirectionality is weaker than the C++ form of
bidirectionality.

For example, suppose you're given some bidirectional range r, with
swappable elements. Clearly, reverse(r) is easily implementable (just
swap .front and .back, then popFront() and popBack() until the range is
empty).

However, suppose you want to reverse the last n elements of r. How would
you do it? Conceptually speaking, if the range is bidirectional, then
its last segment of n elements ought to be bidirectional too, right?
However, there is currently no (easy) way to get a bidirectional
subrange out of r, using the current range primitives.

One brute force way to do it, is to iterate a .save'd copy of r (since
bidirectionality implies forward range) from the front, until there are
only n elements left, then perform the reverse() operation. However,
this is horribly inefficient if n is relatively small w.r.t. the total
number of elements in r. It gets worse if r does not have .length, so
you may have to iterate over *two* .save'd copies of r so that you know
the subrange you end up with has exactly n elements (since you can't
tell how many elements are in the subrange until you reach the end).

Ideally, though, we'd like to be able to iterate from the end of r, so
that we only incur the cost of calling .popBack n times. However, no
amount of trickery with the current bidirectional range API is going to
get you this subrange by iterating from the back. The problem is that
once you call .popBack n times, there's no way to turn .back into the
new .front of the subrange. You can't unpop .back once you've called
popBack(), so you can't implement .front on the subrange.  Whereas with
iterators, you *could* just do iter-- n times, then use iter with the
original .end() to form the n element subrange.

So D's bidirectional ranges are inherently weaker than a pair of C++
bidirectional iterators, because D's bidirectional ranges are, under the
hood, a pair of *uni-directional* iterators in opposite directions. Once
you advance either iterator, you can't go back anymore without resorting
to ugly inefficient hacks (e.g., allocate a stack of .save'd positions),
whereas in C++ both ends are bidirectional, and can go forward/back at
anytime.

If we were to add an .unpop primitive to bidirectional ranges, though,
then we could solve this problem. However, I'm not sure how this fits in
with the overall concept of ranges.

T

-- 
Век живи - век учись. А дураком помрёшь.

Re: Moving back to .NET

2015-10-08 Thread Ola Fosheim Grøstad via Digitalmars-d

On Thursday, 8 October 2015 at 10:59:04 UTC, Ola Fosheim Grøstad 
wrote:
I think D could do well if it focused on engine-level system 
programming and made sure it was absolutely top notch for that 
purpose. (Game engines, search engines, ray tracing engines, in 
memory database engines, business logic engines, etc).


The current focus goes the other way. The current assumption is 
that engines are written in C/C++ and they are used to complete 
applications in D.


What D lacks in comparison to C w.r.t. to writing an engine?

Re: D 2015/2016 Vision?


On Thursday, 8 October 2015 at 16:38:31 UTC, Meta wrote:

Why, because you can take their address?


You or someone you call can take the address. If there is a way 
to distinguish instances one way or another then it isn't a 
value, it is an object. Doesn't mean your code is taking the 
address.

Re: Moving back to .NET

2015-10-08 Thread Ola Fosheim Grøstad via Digitalmars-d


On Thursday, 8 October 2015 at 16:25:09 UTC, Kagamin wrote:
Where do you think is a limit to applicability of a 
turing-complete language?


?

Pointers are of little use for a type that is always reference 
type.


You can have many different types of references.


Make them not compile? @nogc does exactly that.


No, make the features work well without GC or change them.

Reducing GC usage and emscripten backend are actionable if you 
want to work on them.


Changing the language is not "actionable" without creating a fork.

Regarding Emscripten, I don't see much value in spending so much 
work on getting something that isn't good enough to work. A 
higher level approach is needed for compact code gen. Possibly 
also language adjustments.

Re: Beta D 2.069.0-b1

2015-10-08 Thread anonymous via Digitalmars-d-announce

On Thursday 08 October 2015 16:34, anonymous wrote:

> On Thursday 08 October 2015 06:14, extrawurst wrote:
> 
>> `The -property switch has been deprecated.` Does that mean 
>> @property has no effect anymore ?
> 
> Yes.

Correction: @property has at least one effect without -property. typeof acts 
differently on properties vs non-properties.

struct S
{
@property int p();
int n();
}
pragma(msg, typeof(S.init.p)); /* int */
pragma(msg, typeof(S.init.n)); /* int() -- i.e. a function */

I wasn't aware of this before Jonathan M Davis told me [1]. I don't think 
it's specified anywhere, at least I can't find anything.

[1] 
https://github.com/D-Programming-Language/dlang.org/pull/1119#issuecomment-146576866

Re: D 2015/2016 Vision?


On Thursday, 8 October 2015 at 10:05:53 UTC, Kagamin wrote:

On Wednesday, 7 October 2015 at 00:17:37 UTC, bitwise wrote:
If it takes long enough that C++ has reflection, modules, 
ranges, stackless coroutines, concepts, etc, then I gotta be 
honest, I'm gonna start worrying about investing too much time 
in D.


You manage resources with reference counting in C++? How it 
deals with circular references?


Resources don't generally own each other, so this isn't really an 
issue. I had code which would request a resources from a shared 
store, and then the shared store would keep a weak-pointer to the 
resource and give out shared pointers to whoever asked. When no 
one was using the resource anymore, it would be freed 
automatically.


Bit

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 14:05:07 UTC, Jonathan M Davis 
wrote:


Maybe, but having classes be value generally makes no sense, 
because you can't use polymorphism with value types.


This is a huge generalization, and is incorrect. You can still 
use inheritance.



Classes are inherently reference types given their semantics.


Incorrect.

Even in C++ that's the case. It's just that they don't separate 
out classes and structs the way we do. But classes that use 
inheritance have to be used as reference types or all you're 
doing is sharing implementation (which can be done easily 
enough without inheritance).


It _can_ be done, but that doesn't mean that it's _always_ the 
best, or even preferred approach.


 Bit

Re: D 2015/2016 Vision?

2015-10-08 Thread Ola Fosheim Grøstad via Digitalmars-d

On Thursday, 8 October 2015 at 16:14:05 UTC, Jonathan M Davis 
wrote:

On Thursday, 8 October 2015 at 15:59:23 UTC, bitwise wrote:
Again, it's much easier to be careful about this when the 
author's intent is baked into the class.


That may be, but my point was that it doesn't actually 
guarantee that the object is going to be destroyed 
determinstically. That's going to require that the programmer 
using the object know that it's designed to be destroyed 
deterministically and program accordingly. Having it be easier 
for the programmer to figure out whether an object was designed 
that way is definitely a plus, but it doesn't make it so that 
they don't have to worry about it.


- Jonathan M Davis


True. I agree with you on this.

All the time, this idea comes to mind when I see people arguing 
back and forth, thinking that they will eventually converge on 
some perfectly ideal solution which obviates the need for any 
real effort.


 Bit

Re: Go, D, and the GC

2015-10-08 Thread Jonathan M Davis via Digitalmars-d

On Thursday, 8 October 2015 at 15:58:37 UTC, Marco Leise wrote:

Am Mon, 05 Oct 2015 13:42:50 +
schrieb Adam D. Ruppe :

On Monday, 5 October 2015 at 07:40:35 UTC, deadalnix wrote:
> Not on the heap. There are many cases where the destructor 
> won't run and it is allowed by spec. We should do better.

To be fair, if you new a struct in C++ and never delete it, 
the destructor will never run there either. D's in the same 
boat in that regard.

But the D boat reads "Garbage Collector". And besides, D now 
runs dtors on new'd structs. The "many cases" may be different 
ones than you imagine.

It's still the case though that if the GC does not collect a 
struct on the GC heap, its destructor is not going to be run. And 
there's no guarantee that _anything_ on the GC heap will ever be 
collected. That depends on stuff like the memory usage of the 
program. We're better off than we were, because when a struct on 
the GC heap is collected, it's destructor will now be run, 
whereas it wouldn't have been before, but ultimately, it's still 
the same boat as C++ with regards to structs that never get 
collected. It's just that in C++, you don't usually let memory 
leak like that, whereas a GC doesn't normally collect everything 
when the program shuts down. So, you're unlikely to run into a 
case in C++ where a struct never gets destroyed, whereas it's 
pretty easy in D.

- Jonathan M Davis

Re: D 2015/2016 Vision?


On Thursday, 8 October 2015 at 16:17:49 UTC, bitwise wrote:

Classes are inherently reference types given their semantics.


Incorrect.


Inaccurate maybe, but something that has an identity is not a 
value type. Value types are by definition identity-less. The type 
system of C/C++/D doesn't really provide guarantees needed to 
have proper value types.

Re: Moving back to .NET