Re: Beta D 2.069.0-b1

[Iain Buclaw via Digitalmars-d-announce]

On 10 October 2015 at 14:51, Jacob Carlborg via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On 2015-10-10 03:52, Martin Nowak wrote:
>
> Scala and Ruby seem to do well with sloppy parens.
>>
>
> A few notes about why Ruby doesn't have the same problems as D has:
>
> 1. Ruby has optional parentheses for all method calls, regardless if they
> accept arguments or not
>
> 2. Ruby has a different syntax for calling lambdas from calling functions:
>
> def foo
> end
>
> foo() # calling function
>
> a = -> { }
> a.call # calling lambda
> a.() # alternative syntax for calling lambda
>
> In Ruby, no one will ever use empty parentheses for calling a method.
>
> 3. You can not use the setter syntax for a "regular" method taking one
> argument:
>
> class Foo
>   def bar(a)
>   end
>
>   def foo=(a) # not the same name as "foo"
>   end
> end
>
> a = Foo.new
> a.bar = 3 # error
> a.foo = 3 # ok
> a.foo(3) # error
>
>
It seems to be a misfeature of D to accept the equivalent of all three of
those examples as valid.

[Issue 15181] SYSCONFDIR is broken

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/d9ba17e95c7ed1aca32f0ee6a1360684ca42f16c
fix Issue 15181 - SYSCONFDIR is broken

https://github.com/D-Programming-Language/dmd/commit/5df7520d7ebc009ff9cc914533bd27424b8b3e9f
Merge pull request #5179 from John-Colvin/patch-3

fix Issue 15181 - SYSCONFDIR is broken

--

[Issue 15181] SYSCONFDIR is broken

[via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: Marketing for D: Making D an official Cloud Foundry built-in language

[Andre via Digitalmars-d]

On Saturday, 10 October 2015 at 02:49:23 UTC, Rikki Cattermole 
wrote:



[...]


Wrong way round. Bundle dub with dmd is already planned.



I hoped 2.069 already contains dub, maybe with 2.070


[...]


I am sure Walter will have no problem with you creating a 
custom archive, perhaps with tar? If that suits you better. 
Check with him however.



[...]


That may not be possible. Unless you want to make dub dependent 
upon git. Which it currently isn't. Right now it uses e.g. 
Github to create an archive of the repository and download that.

Although some trade off will be possible.

Also it all goes through code.dlang.org the last I remember.



yes it would depend on git. I suggest a new dub attribute. The
value starts with a protocol. Like file:// if it is a zip on the 
local

pc or a file on a file server. git:// if it is a git repository.


[...]


It exists, the support is there. Just not in the dub 
configuration file. It is something that would be nice to have.


This feature would also be a "work around" for 4). I will file 
feature

requests

LDC 0.16.0 beta2 is out! Try out before we create the final release!

[Kai Nacke via Digitalmars-d-announce]

Hi everyone,

LDC 0.16.0 beta2, the LLVM-based D compiler, is available for 
download!
This release is based on the 2.067.1 frontend and standard 
library and supports LLVM 3.1-3.7 (OS X: no support for 3.3).


Don't miss to check if your preferred system is supported by this 
release. We also have a Win64 compiler available!


As usual, you can find links to the changelog and the binary 
packages over at digitalmars.D.ldc:

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

Regards,
Kai

Re: How to check whether an empty array variable is null?

[rumbu via Digitalmars-d-learn]

On Saturday, 10 October 2015 at 15:20:04 UTC, tcak wrote:

[code]
int[] list;

list = new int[0];

std.stdio.writeln("Is Null ? ", (list is null));
[/code]

Result is "Is Null? true".

Is this the correct behaviour? I would expect compiler to point 
to an address in the heap, but set the length as 0. So, it 
wouldn't return null, but the length would be 0 only.



Long discussion: 
http://forum.dlang.org/thread/rrrtkfosfnfuybble...@forum.dlang.org

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

[H. S. Teoh via Digitalmars-d]

On Sat, Oct 10, 2015 at 06:06:59PM +, Eric Niebler via Digitalmars-d wrote:
> On Saturday, 10 October 2015 at 06:15:10 UTC, Andrei Alexandrescu wrote:
[...]
> >Anyhow, it's best for us all to focus on doing good work instead of
> >pettily fighting for irrelevant credit.
> 
> I only jumped in when I saw some disparagement of C++ and my work
> which (IMO) was both petty and wrong. I would very much like to drop
> this and get back to productive work.
[...]

Eric, if I came across as disparaging your work, I apologize, as that
was never my intention. As the author of the article that you used as
the basis for your presentation, I am very honored to have you
acknowledge my work in the C++ community.

My comment about C++ playing catchup wasn't intended to be petty
disparagement either, it's a reflection of my consideration that C++ has
been heading in the wrong direction (IMO), and only now is "turning the
ship", so to speak, toward where other languages have already gone
ahead.  I'm a C++ programmer myself, and for many years have faced many
problems and issues that arose from certain design decisions in C++.
After discovering D and realizing that I don't *need* to deal with such
issues after all, because D made different design decisions, only to
learn later on that C++ is now also trying to head in the same
directions, it's a bit hard not to perceive C++ as playing catch-up.


T

-- 
Gone Chopin. Bach in a minuet.

How to check whether an empty array variable is null?

[tcak via Digitalmars-d-learn]

[code]
int[] list;

list = new int[0];

std.stdio.writeln("Is Null ? ", (list is null));
[/code]

Result is "Is Null? true".

Is this the correct behaviour? I would expect compiler to point 
to an address in the heap, but set the length as 0. So, it 
wouldn't return null, but the length would be 0 only.

Re: Hash-Table-Based Multiple Arguments Replacement

[Nordlöw via Digitalmars-d-learn]

On Saturday, 10 October 2015 at 16:19:53 UTC, Nordlöw wrote:
Is there an algorithm somewhere in Phobos which performs when 
possible a replacement/substitution based on a variadic 
definition of replacements using hash-table search similar to


Found it:

http://dlang.org/phobos/std_algorithm_comparison.html#predSwitch

An alias would be perhaps be motivated to make newcomers easier 
grap that this can be used for whole replacements.

Hash-Table-Based Multiple Arguments Replacement

[Nordlöw via Digitalmars-d-learn]

Is there an algorithm somewhere in Phobos which performs when 
possible a replacement/substitution based on a variadic 
definition of replacements using hash-table search similar to


string replaceWhole(string a)
{
switch (x)
{
case "a": return "1";
case "b": return "2";
default:  return x;
}
}

?

Desired interface

y = x.replaceWhole!("a","x",
"b","y",
"c","z")

or perhaps

y = x.replaceWhole!(tuple("a","x"),
tuple("b","y"),
tuple("c","z"))


kind of like

"a".among!("a", "b", "c")

but for replacements.

Re: Beta D 2.069.0-b1

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Saturday, 10 October 2015 at 12:51:43 UTC, Jacob Carlborg 
wrote:
In Ruby, no one will ever use empty parentheses for calling a 
method.


That's actually the same as Simula. Functions/procedures with no 
parameters is called without parentheses.

[Issue 15177] [REG2.069.0-b1] mixin + traits issue with 2.069 beta 1

[via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/f26ae0052ec82c61d63247096c78503caab8ce9d
fix Issue 15177 - mixin + traits issue with 2.069 beta 1

https://github.com/D-Programming-Language/dmd/commit/d752f698caaaec89a52630e3255d576bb03cd9f9
Merge pull request #5172 from 9rnsr/fix15177

[REG2.069.0-b1] Issue 15177 - mixin + traits issue with 2.069 beta 1

--

[Issue 15177] [REG2.069.0-b1] mixin + traits issue with 2.069 beta 1

[via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 15177] [REG2.069.0-b1] mixin + traits issue with 2.069 beta 1

[via Digitalmars-d-bugs]

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

--- Comment #3 from Martin Nowak  ---
This was about __traits(allMembers, mymod) listing generated
TypeInfoStructDeclaration members.

--

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

[H. S. Teoh via Digitalmars-d]

On Sat, Oct 10, 2015 at 09:52:22AM +0300, Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 10/10/15 12:58 AM, Eric Niebler wrote:
> >Trying to express algorithms without any clear abstraction of
> >"position within range" (independent of ranges) is hard and awkward,
> >and occasionally causes algorithms to be less efficient.
> 
> I agree that ranges are a weaker basis than iterators. But it's not
> necessarily that a notion of position is the only way out.
> 
> Ranges can be made as strong a basis by adding the O(1) primitives
> r1.before(r2) and r1.after(r2) that return the prefix/suffix following
> r2 within r1. With those I hope to be able to show easily that
> algorithms needing "iterator in the middle" can be redone.

I assume .before would be implemented in a specialization of forward
ranges, and .after in a specialization of bidirectional ranges?


> I think I need to sit down and define these primitives (albeit they
> aren't used that frequently) and use them in a few fundamental
> algorithms to just close the matter once and for all.
[...]

It would also fix the current bug in nextPermutation that claims that it
supports bidirectional ranges, when in fact it requires random access
ranges, precisely because reversing the last n elements requires the
"iterator in the middle" construct.


T

-- 
Gone Chopin. Bach in a minuet.

Re: How to check whether an empty array variable is null?

[Meta via Digitalmars-d-learn]

On Saturday, 10 October 2015 at 15:20:04 UTC, tcak wrote:

[code]
int[] list;

list = new int[0];

std.stdio.writeln("Is Null ? ", (list is null));
[/code]

Result is "Is Null? true".

Is this the correct behaviour? I would expect compiler to point 
to an address in the heap, but set the length as 0. So, it 
wouldn't return null, but the length would be 0 only.


Yes, it's correct behaviour. `array is null` checks whether 
array.ptr is null, which is the case for a 0-length array.


void main()
{
auto a = new int[0];
writeln(a.ptr);  //a.ptr is null

auto a2 = new int[1];
writeln(a2.ptr); //a2.ptr is not null
a2 = a[0..$];//Slice off the only element of a2
writeln(a2.ptr); //Now a2.ptr is null
}

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

[Eric Niebler via Digitalmars-d]

On Saturday, 10 October 2015 at 06:15:10 UTC, Andrei Alexandrescu 
wrote:

On 10/10/15 12:58 AM, Eric Niebler wrote:
To be honest, this whole conversation is kind of funny to me. 
It
reminds me of the Bugs Bunny cartoon where Marvin the Martian 
plants

his flag on Earth and says, "I claim this planet in the name of
[Digital] Mars!" We Earthlings respectfully disagree. :-)


Only it's the other way around, which makes the matter quite 
ironic. You wrote:


P.S. I see lots of people here assuming that C++ is playing 
catch-up
to D because D has ranges and C++ doesn't yet. That is 
ignoring the
long history of ranges in C++. C++ got ranges in the form of 
the
Boost.Range library by Thorsten Ottoson sometime in the early 
00's.
Andrei didn't implement D's ranges until many years after. The 
ranges

idea is older than dirt. It's not a D invention.


I think it would be a bit of a stretch to describe D ranges as 
derivative of Boost ranges.


If I implied that I believe that D ranges were based on 
Boost.Range, then I apologize. I don't believe that. I suspect 
(but don't know) that ranges in D were independently invented 
without knowledge of the long history of them in C++. Which is 
fine except for the claims that C++ is playing catch-up. It's not.


Anyhow, it's best for us all to focus on doing good work 
instead of pettily fighting for irrelevant credit.


I only jumped in when I saw some disparagement of C++ and my work 
which (IMO) was both
petty and wrong. I would very much like to drop this and get back 
to productive work.


\e

Re: Beta D 2.069.0-b1

[Jonathan M Davis via Digitalmars-d-announce]

On Saturday, October 10, 2015 02:57:01 Meta via Digitalmars-d-announce wrote:
> On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak wrote:
> > That's what I meant, weird use-case, at best it's a callback
> > better/setter.
> > I've never written such code, but even if you would, the 2
> > pairs of parens are only a tiny problem for generic code,
> > nothing to warrant the invasive language feature @property is.
>
> I don't know how much metaprogramming-heavy generic code you've
> written, but I can say from first-hand experience that there is
> such a thing as Hell, and it is called Optional Parens.

Optional parens definitely do not help with generic code - quite the
opposite. In generic code, it needs to be clear whether a symbol is supposed
to represent a field or a function. If it's a field, you call it without
parens. If it's a function, it has to be called with parens if it's supposed
to be possible to have the symbol emulate a function rather than be a
function (e.g. be a delegate).

We mostly get away with optional parens on function calls in generic code,
because it's pretty rare that we write code that's expecting a function and
is given a delegate, except in the cases (like predicates) where we clearly
expect any kind of callable, and we have to use template wrappers (e.g.
std.functional.binary) in those cases in order to make them all act the same
and not care about what exactly we're getting.

For symbols that are supposed to act like fields, they can't be called with
parens in generic code, or they won't work generically, and unlike with
symbols that are supposed to act like functions, it's _very_ common to get a
mix of variables and functions for the same symbol across different types.
So, generic code that uses parens on what is supposed to be a field will
work with a function but fail miserably if the type it's given implemented
that symbol as a variable. And that's common enough that generic code needs
to get it right, whereas it can mostly get away with it with symbols that
represent functions simply due to the fact that they're pretty much always
implemented as functions.

I don't think that there's any question that generic code would be better
off if we didn't have optional parens and if functions which used the
property syntax weren't allowed to be called with parens. And D programs
typically have a lot of generic code.

The problem is that when folks are writing code that uses generic functions
(rather than necessarily being inside of generic functions), they like to
leave off the parens and think that it's ugly to be required to have them.
So, we don't have full property enforcement and will never get it. But that
same laxity inside of generic code easily leads to compilation failures when
properties are used simply because a function will work with parens (be it
an @property function or not) whereas variables won't.

Hands down, I think that we'd be better off with strict property enhancement
due to all of the generic code that we deal with, but that water is long
since under the brigde.

Instead, we're forever going to be forced to be even more thorough with unit
testing in order to make sure that templated functions don't use parens on
symbols that are supposed to be properties/fields and to make sure that it
does use parens on something that is supposed to be a function. Since, any
time we don't do that, we risk making mistakes and writing generic code that
doesn't work with all of the types that it's supposed to work with.

The only question at this point is whether we can at least get partial
property enforcement out of @property and reduce the number of bugs in
generic code or whether @property is pretty much just going to be tossed
out.

- Jonathan M Davis

Re: AWS API Dlang, hmac sha256 function.

[holo via Digitalmars-d-learn]

On Friday, 9 October 2015 at 16:30:26 UTC, holo wrote:
OK i find out error, in addRequestHeader i was using ":" after 
header name what casing problem. I removed it and now im 
getting "unauthorized". Here is how it looks right now:


 HTTP/1.1 401 Unauthorized\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 401 
Unauthorized\r\n]

Request Version: HTTP/1.1
Status Code: 401
Response Phrase: Unauthorized
Transfer-Encoding: chunked\r\n
Date: Fri, 09 Oct 2015 16:22:47 GMT\r\n
Server: AmazonEC2\r\n
\r\n
[HTTP response 1/2]
[Next request in frame: 8371]
HTTP chunked response
Data chunk (254 octets)
Chunk size: 254 octets
Data (254 bytes)

In data field i can read:

"AWS was not able to validate provided access credentials" Is 
my signing process incorrect?


Maybe i will put my present code again:

#!/usr/bin/rdmd -L-lcurl

import std.stdio;
import std.string;
import std.file;
import std.datetime;
import std.process;
import std.digest.sha;
import std.net.curl;
import std.uri;
import sigv4;


auto zone = "us-east-1";
auto service = "ec2";


void main()
{
auto accKey = environment["AWS_ACCESS_KEY"];
auto secKey = environment["AWS_SECRET_KEY"];

auto currentClock = Clock.currTime;

auto currentDate = cast(Date)currentClock;
auto curDateStr = currentDate.toISOString;

auto currentTime = cast(TimeOfDay)currentClock;
auto curTimeStr = currentTime.toISOString;

auto xamztime = curDateStr ~ "T" ~ curTimeStr ~ "Z";

string[string] empty;

SignableRequest r;
r.dateString = curDateStr;
r.timeStringUTC = curTimeStr;
r.region = zone;
r.service = service;
r.canonicalRequest = CanonicalRequest(
"POST",
"/",
["action" : "DescribeInstances", "version" : 
"2013-10-15"],
//  ["accept" : "*/*",
			["content-type" : "application/x-www-form-urlencoded; 
charset=utf-8",

 "host" : service ~ ".amazonaws.com",
 "x-amz-date" : xamztime],
			 cast(ubyte[])"");  
//cast(ubyte[])"Action=DescribeInstances=2013-10-15");


	auto qParm = 
canonicalQueryString(r.canonicalRequest.queryParameters);


auto sigHead = canonicalHeaders(r.canonicalRequest.headers);

auto sigStr = signableString(r);

auto sigKey = signingKey(secKey, curDateStr, zone, service);

	auto signature = sign(sigKey, 
cast(ubyte[])sigStr).toHexString().toLower();


writeln();  
writeln(qParm);
writeln();
writeln(sigHead);
writeln();
writeln(sigStr);
writeln();
writeln(signature);
writeln();
auto client = HTTP();
//  client.clearRequestHeaders;
	client.addRequestHeader("content-type", 
"application/x-www-form-urlencoded; charset=utf-8");

client.addRequestHeader("host", service ~ ".amazonaws.com");
client.addRequestHeader("x-amz-date", xamztime);
	client.addRequestHeader("authorization", "AWS4-HMAC-SHA256" ~ " 
" ~ "Credential=" ~ accKey ~ "/" ~ xamztime ~ "/" ~ zone ~ "/" ~ 
service ~ "/" ~ "aws4_request" ~ ", " ~ "SignedHeaders=" ~ 
"content-type;host;x-amz-date" ~ ", " ~ "Signature=" ~ signature);


	auto url = "ec2.amazonaws.com/?" ~ 
"Action=DescribeInstances=2013-10-15";

auto urlenc = encode(url);
writeln(url);
auto content = get(urlenc, client);
writeln(content);
}

Is my signing process correct?

[Issue 12624] Internal error: backend\cgobj.c 2313 with Rebindable!(immutable TimeZone) in std.datetime

[via Digitalmars-d-bugs]

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

--- Comment #2 from Jonathan M Davis  ---
Well, this is a finicky one. I'd tried to reduce the failing code to something
more manageable in the past and failed, but I thought that I'd take another
stab at it, and simply copying the entire std.datetime module to a module
separate from Phobos (and changing the module declaration of course) and then
doing

Rebindable!(immutable TimeZone) _timezone = UTC();

works instead of failing like it does when that line is changed inside of
Phobos.

It wouldn't surprise me if this problem simply went away when I finally split
of std.datetime (which I think that I'm going to take another stab at getting
done shortly) simply due to how specific the failure is - which just means that
the compiler bug would then be hidden away again rather than anything truly
having been fixed (which certainly isn't good), but if it went away like that,
at least it wouldn't be blocking improvements to SysTime anymore.

--

Re: Hash-Table-Based Multiple Arguments Replacement

[Nordlöw via Digitalmars-d-learn]

On Saturday, 10 October 2015 at 16:42:52 UTC, Nordlöw wrote:

Found it:

http://dlang.org/phobos/std_algorithm_comparison.html#predSwitch

An alias would be perhaps be motivated to make newcomers easier 
grap that this can be used for whole replacements.


Ahh, but this doesn't use a hash-table because it doesn't support 
taking its arguments as CT-params...so that doesn't qualify.


Maybe we should add a new CT-param-only overload for `predSwitch` 
similar to `among`?


Destroy!

Compile time and runtime grammars

[DLangLearner via Digitalmars-d-learn]

Only now I found that most of my confusions are with D's compile 
time grammar or features. As an excuse, my confusions can be 
partially attributed to the way D is presented:


1. There are confusing keywords:
For example, there is a "if", there is also a "static if", there 
is a "if", and there is an "is()". For new learners like me, they 
cause confusion at least uneasiness.


2. Compile time grammar spreads among runtime grammar
Most documents present D's compile time grammar and runtime 
grammar in the same time. It made me feel that D's grammar is not 
consistent because compile time grammar seem to be exceptions 
from runtime grammar. If a document talks exclusively about 
runtime grammar first, and
introduces compile time grammar late, I think this will make 
readers accept those seemingly conflicting grammar. In fact 
without introducing compile time grammar, D is much similar to 
other languages, in this way the readers from other languages can 
find D more friendly.


With the understanding of D's compile time grammar, I can read D 
codes from other projects such as std packages, but I am still 
not easy about the way that D's compile time codes are not 
clearly distinguished from runtime codes. I am wondering if it is 
a good idea to clearly indicate those compile time codes with a 
special identifier say "@ct", or prefix "__" as in __traints, if 
so then those "inconsistencies" can be resolved as follows:


static if -> @ct if
static assert" -> @ct assert
enum fileName = "list.txt" -> @ct  fileName = "list.txt"
is (string[void]) -> @ct is (string[void])
mixin(`writeln("Hello World!");`) -> @ct `writeln("Hello 
World!");`


So this post is not quite a question, just a thought in my mind 
after I am able to differentiate compile time codes from runtime 
codes.

Re: Compile time and runtime grammars

[H. S. Teoh via Digitalmars-d-learn]

On Sat, Oct 10, 2015 at 06:52:29PM +, DLangLearner via Digitalmars-d-learn 
wrote:
> Only now I found that most of my confusions are with D's compile time
> grammar or features. As an excuse, my confusions can be partially
> attributed to the way D is presented:
> 
> 1. There are confusing keywords:
> For example, there is a "if", there is also a "static if", there is a
> "if", and there is an "is()". For new learners like me, they cause
> confusion at least uneasiness.

I assume by the second "if" you meant "is".  It's well-known that the
syntax of is() could be better. Unfortunately, the ship has long since
sailed, and there's not much point in breaking existing code just to
make some cosmetic changes.

The "static" in "static if" is clear indication that this isn't a
regular if-statement, but a branch that's taken at compile-time. I'm not
sure how else it can be made clearer.


> 2. Compile time grammar spreads among runtime grammar
> Most documents present D's compile time grammar and runtime grammar in
> the same time. It made me feel that D's grammar is not consistent
> because compile time grammar seem to be exceptions from runtime
> grammar. If a document talks exclusively about runtime grammar first,
> and introduces compile time grammar late, I think this will make
> readers accept those seemingly conflicting grammar. In fact without
> introducing compile time grammar, D is much similar to other
> languages, in this way the readers from other languages can find D
> more friendly.
> 
> With the understanding of D's compile time grammar, I can read D codes
> from other projects such as std packages, but I am still not easy
> about the way that D's compile time codes are not clearly
> distinguished from runtime codes. I am wondering if it is a good idea
> to clearly indicate those compile time codes with a special identifier
> say "@ct", or prefix "__" as in __traints, if so then those
> "inconsistencies" can be resolved as follows:
> 
> static if -> @ct if
> static assert" -> @ct assert
> enum fileName = "list.txt" -> @ct  fileName = "list.txt"
> is (string[void]) -> @ct is (string[void])
> mixin(`writeln("Hello World!");`) -> @ct `writeln("Hello World!");`
> 
> So this post is not quite a question, just a thought in my mind after
> I am able to differentiate compile time codes from runtime codes.

Actually, this shows a misunderstanding of what D's compile-time
features actually do, and also shows that the terminology "compile-time"
itself is a bit misleading. This is likely the fault of the way these
features are described in the documentation.

In D, there are actually (at least) two (very!) distinct categories of
compile-time features:

There's the template system, which is mainly concerned with manipulating
the syntax tree of the code.  This provides the meta-programming
features of D, and runs quite early on in the compilation process.

There's also the CTFE system (compile-time function evaluation), which
is mainly concerned with *executing code* inside the compiler, at
runtime, after the syntax tree has been generated, which is later in the
compilation process. Obviously, this can only be done after the syntax
tree has been fixed, otherwise the semantics of the code would be
undefined or inconsistent.

The two are closely-related, and the difference may seem to be subtle,
but this is extremely important to understand in order to understand how
to use these features effectively.

For example, "static if" is a feature belonging to the template system,
and is concerned with manipulating the syntax tree of the program before
the compiler runs its semantic passes over it.  The branch is evaluated
*before* CTFE even sees the code; and that's why the following code does
*not* work:

int func(bool x) {
static if (x)
return 1;
else
return 2;
}
enum y = func(1);

The first problem is that the static-if is asking the compiler to
evaluate x. Theoretically speaking, this should work, since x is known
at "compile-time", but when the static-if is being processed, the syntax
tree of func() isn't even completed yet, so the compiler has no way of
knowing what x might be referring to.

The second problem is that the value of the enum is processed by CTFE,
but since the static-if is processed before CTFE even sees the code, by
the time CTFE runs it's already too late for the static-if to decide
which branch should be taken. Static-if means that the branch of code
that isn't taken, doesn't even exist in the syntax tree of the program;
it's as if the programmer deleted those lines from the source file.

So you see, the term "compile-time" is actually ambiguous, because there
are actually two distinct phases of compilation here, and intermixing
them doesn't make sense.

The correct version of the above code is:

int func(bool x) {
if (x)  // <--- N.B. no "static"

Re: How to check whether an empty array variable is null?

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, October 10, 2015 15:20:02 tcak via Digitalmars-d-learn wrote:
> [code]
>   int[] list;
>
>   list = new int[0];
>
>   std.stdio.writeln("Is Null ? ", (list is null));
> [/code]
>
> Result is "Is Null? true".
>
> Is this the correct behaviour? I would expect compiler to point
> to an address in the heap, but set the length as 0. So, it
> wouldn't return null, but the length would be 0 only.

It basically didn't bother to allocate an array on the heap, because you
asked for one with a length of zero. Efficiency-wise, it makes no sense to
allocate anything. You wouldn't be doing anything with the memory anyway.
The only way that you're going to get an array of length 0 which doesn't
have a null ptr is to slice an array down to a length of 0.

- Jonathan M Davis

DIP74 - where is at?

[Manu via Digitalmars-d]

So I have another upcoming opportunity to introduce D in my workplace,
this time as a front-end/plugin language to our C++ infrastructure,
which is promising since I already have considerable experience in
this area (my work at Remedy with Quantum Break), and there is a lot
of recent work to interact better with C++, which we will stress-test
extensively.

You only get so many shots at this; but this is a particularly
promising opportunity, since the C++ code is a nightmare, and the
contrast against D will allow a lot of coders to see the advantage.

There is however one critical missing feature, DIP74... where is it at
currently? How is it going? Is it likely to be accepted in the
near-term? Some sort of approximate timeline?

I think it would be a mistake for me to introduce this without DIP74,
since we will rely on it VERY heavily, and the machinery to
work-around it will start to look just as heavy-weight as the C++ code
I'm trying to deprecate... but then waiting on it starts to look like
missing the window of opportunity.

Thoughts?

Re: -> and :: operators

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 10 October 2015 at 22:54:15 UTC, Warwick wrote:
On Friday, 9 October 2015 at 19:48:39 UTC, Dmitry Olshansky 
wrote:

On 09-Oct-2015 21:44, Freddy wrote:


Stole from D? You mean java right?


There is no value type objects in Java so no. More likely C#.


Delphi / Object Pascal had it in the mid 90s IIRC. Long before 
C#, and possibly before Java was released.


Simula is the origin, it came about in the 60s.

Re: DIP74 - where is at?

[Manu via Digitalmars-d]

I'm rather in favour of DIP74... what's unprincipled about it? What
would you do instead?

On 11 October 2015 at 10:20, deadalnix via Digitalmars-d
 wrote:
> On Saturday, 10 October 2015 at 23:25:49 UTC, Manu wrote:
>>
>> So I have another upcoming opportunity to introduce D in my workplace,
>> this time as a front-end/plugin language to our C++ infrastructure, which is
>> promising since I already have considerable experience in this area (my work
>> at Remedy with Quantum Break), and there is a lot of recent work to interact
>> better with C++, which we will stress-test extensively.
>>
>> You only get so many shots at this; but this is a particularly promising
>> opportunity, since the C++ code is a nightmare, and the contrast against D
>> will allow a lot of coders to see the advantage.
>>
>> There is however one critical missing feature, DIP74... where is it at
>> currently? How is it going? Is it likely to be accepted in the near-term?
>> Some sort of approximate timeline?
>>
>> I think it would be a mistake for me to introduce this without DIP74,
>> since we will rely on it VERY heavily, and the machinery to work-around it
>> will start to look just as heavy-weight as the C++ code I'm trying to
>> deprecate... but then waiting on it starts to look like missing the window
>> of opportunity.
>>
>> Thoughts?
>
>
> It doesn't looks like it is getting implemented. And, to be honest, I'd
> rather go a principle approach + library support rather than a pie of hacks.
>
> The pile of hacks approach is what made C++ C++.
>

Re: DIP74 - where is at?

[deadalnix via Digitalmars-d]

On Sunday, 11 October 2015 at 04:35:03 UTC, Jonathan M Davis 
wrote:

On Sunday, 11 October 2015 at 04:16:11 UTC, deadalnix wrote:
If we go these DIP road, there is no coming back and this will 
get in the way of a principled approach.


Then come up with an alternative DIP which shows a better way 
to solve this. As it stands, it looks likely that we'll end up 
with some form of DIP 74, and if you have a better proposal, 
then now is probably the time to do it.




I have, other have as well, in fact there was a lengthy 
discussion in private between Walter, Andrei, myself and some 
other where very precise proposal has been made.


I'm sorry but that's bullshit. I'm tired of reexplaining the same 
thing again and again while is it clear that nobody cares about 
facts here. If people would care about facts, the DIP25 fiasco 
would have been enough to put the ideas back on the table.


The one place in-language where I'm sure that something like 
RefCounted doesn't do it is exceptions, since we really should 
have a way to make those reference counted, but you can only 
throw something derived from Throwable - which means a class 
and not a wrapper around one. So, we need a tweak of some kind 
to the language there, but that's pretty specific, whereas it 
_should_ be possible to get something like RefCounted to at 
least solve the normal cases. Clearly though, Walter and Andrei 
have come to the conclusion that it's not.




Proposal included solution for this problem. Exception ownerhip 
is transferred to the runtime when thrown, and the runtime 
transfer it back to the catch block that effectively catches it.

[Issue 15166] [REG2.069-devel] spurious statement not reachable warning in static foreach loop

[via Digitalmars-d-bugs]

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

--- Comment #2 from Martin Nowak  ---
This is as annoying as go's stupid "unused variable" warning, at least during
development.

> I'm not sure how we can "fix" this and issue 14835.

I guess the fix would be to mark those returns as dependent on the template
types and not account for them when computing not reachable statements, but
that sounds like quite a difficult change.
I guess we might fix this in vibe.d but it might break a lot more code.

--

Re: Hash-Table-Based Multiple Arguments Replacement

[Meta via Digitalmars-d-learn]

On Saturday, 10 October 2015 at 16:19:53 UTC, Nordlöw wrote:
Is there an algorithm somewhere in Phobos which performs when 
possible a replacement/substitution based on a variadic 
definition of replacements using hash-table search similar to


string replaceWhole(string a)
{
switch (x)
{
case "a": return "1";
case "b": return "2";
default:  return x;
}
}

?

Desired interface

y = x.replaceWhole!("a","x",
"b","y",
"c","z")

or perhaps

y = x.replaceWhole!(tuple("a","x"),
tuple("b","y"),
tuple("c","z"))


kind of like

"a".among!("a", "b", "c")

but for replacements.


There was something like this proposed quite awhile ago (can't 
remember what it was, might've been extending unary/binaryFun to 
accept an AA), but it was rejected.

Re: How to check whether an empty array variable is null?

[Meta via Digitalmars-d-learn]

On Sunday, 11 October 2015 at 00:18:54 UTC, Meta wrote:
On Saturday, 10 October 2015 at 20:07:11 UTC, Jonathan M Davis 
wrote:
It basically didn't bother to allocate an array on the heap, 
because you asked for one with a length of zero. 
Efficiency-wise, it makes no sense to allocate anything. You 
wouldn't be doing anything with the memory anyway. The only 
way that you're going to get an array of length 0 which 
doesn't have a null ptr is to slice an array down to a length 
of 0.


- Jonathan M Davis


Look at my second example.


Sorry, I thought you were responding to me.

Re: How to check whether an empty array variable is null?

[Meta via Digitalmars-d-learn]

On Saturday, 10 October 2015 at 20:07:11 UTC, Jonathan M Davis 
wrote:
It basically didn't bother to allocate an array on the heap, 
because you asked for one with a length of zero. 
Efficiency-wise, it makes no sense to allocate anything. You 
wouldn't be doing anything with the memory anyway. The only way 
that you're going to get an array of length 0 which doesn't 
have a null ptr is to slice an array down to a length of 0.


- Jonathan M Davis


Look at my second example.

Re: DIP74 - where is at?

[Jonathan M Davis via Digitalmars-d]

On Sunday, 11 October 2015 at 04:16:11 UTC, deadalnix wrote:
If we go these DIP road, there is no coming back and this will 
get in the way of a principled approach.


Then come up with an alternative DIP which shows a better way to 
solve this. As it stands, it looks likely that we'll end up with 
some form of DIP 74, and if you have a better proposal, then now 
is probably the time to do it.


Personally, I obviously haven't been following this closely 
enough, because I don't understand why something like RefCounted 
can't be made to do what we need with regards to reference 
counting and classes. It does get a bit nasty when inheritance 
and whatnot get involved, but C++ was able to solve that easily 
enough, and we should be able to do the same.


The one place in-language where I'm sure that something like 
RefCounted doesn't do it is exceptions, since we really should 
have a way to make those reference counted, but you can only 
throw something derived from Throwable - which means a class and 
not a wrapper around one. So, we need a tweak of some kind to the 
language there, but that's pretty specific, whereas it _should_ 
be possible to get something like RefCounted to at least solve 
the normal cases. Clearly though, Walter and Andrei have come to 
the conclusion that it's not.


- Jonathan M Davis

Re: DIP74 - where is at?

[Jonathan M Davis via Digitalmars-d]

On Sunday, 11 October 2015 at 00:20:08 UTC, deadalnix wrote:
It doesn't looks like it is getting implemented. And, to be 
honest, I'd rather go a principle approach + library support 
rather than a pie of hacks.


The pile of hacks approach is what made C++ C++.


AFAIK, Walter and Andrei are still in favor of something that's 
at least similar to DIP 74. Andrei made a comment in a thread 
just the other day that indicated that he was in favor of having 
a way to build reference counting into classes. So, I don't know 
why you think that it's not going to be implemented other than 
the fact that it hasn't been implemented yet. It wouldn't 
surprise me if the DIP needed some tweaking though.


Regardless, now is not the best time to ask this sort of 
question, because Walter and Andrei are on their trip to Romania, 
and they're going to have a limited presence in the newsgroup at 
the moment.


It wouldn't surprise me though if something like the possibility 
of getting D into another company relied on something like DIP 74 
helped push it along and got it sorted out faster. Clearly, 
Walter and Andrei think that it's an issue and have done some 
work on it at the theoretical level, but I don't know where it 
sits on their priority list. And even if DIP 74 were fully sorted 
out tomorrow, it would still require Walter or someone else 
actually implementing it, and that's probably not a small 
undertaking.


- Jonathan M Davis

Re: Hash-Table-Based Multiple Arguments Replacement

[Nordlöw via Digitalmars-d-learn]

On Sunday, 11 October 2015 at 00:16:44 UTC, Meta wrote:
There was something like this proposed quite awhile ago (can't 
remember what it was, might've been extending unary/binaryFun 
to accept an AA), but it was rejected.


With static foreach in a switch we can do better. I'll put 
together a solution.

Re: DIP74 - where is at?

[deadalnix via Digitalmars-d]

On Sunday, 11 October 2015 at 05:18:26 UTC, Jonathan M Davis 
wrote:
Well, if they won't listen, they won't listen. And if they're 
wrong, we'll be worse off for it. Unfortunately, I wasn't 
involved in those discussions and haven't looked into DIP 25 
much (I was too busy at the time of the major discussion for it 
IIRC). So, I'm not familiar enough with it to have a properly 
informed opinion. But convincing Walter and Andrei is typically 
pretty difficult. They do come around eventually at least some 
of the time though. So, as frustrating as such discussions can 
be, they do bear fruit at least some of the time (whether it's 
by them convincing you or by you convincing them). And since 
DIP 25 has only been implemented with a flag rather than adding 
it to the language proper yet, there's still time to convince 
them before we're fully committed to it - as difficult as 
convincing them may be.


- Jonathan M Davis


Truth be told at the time I was doubtful a DIP25 like approach, 
but willing to give it a try. They had me convinced of that much. 
Maybe that wasn't that powerful, but maybe that was powerful 
enough for basics uses cases and would cut it.


Seeing what comes out of it confirmed that no, it won't, and once 
you get DIP25 + DIP74 you are in the same ballpark as other 
proposals in term of language additions, but barley measure in 
terms of capabilities.

Re: DIP74 - where is at?

[Freddy via Digitalmars-d]

On Saturday, 10 October 2015 at 23:25:49 UTC, Manu wrote:

[...]


Speaking of DIP74 can't we just wrap a class in a struct with use 
reference counting with and use alias this?

Re: -> and :: operators

[Warwick via Digitalmars-d]

On Friday, 9 October 2015 at 19:48:39 UTC, Dmitry Olshansky wrote:

On 09-Oct-2015 21:44, Freddy wrote:


Stole from D? You mean java right?


There is no value type objects in Java so no. More likely C#.


Delphi / Object Pascal had it in the mid 90s IIRC. Long before 
C#, and possibly before Java was released.

Re: Run D on AWS Lambda

[Laeeth Isharc via Digitalmars-d-announce]

On Sunday, 26 July 2015 at 03:55:17 UTC, Laeeth Isharc wrote:

https://aws.amazon.com/lambda/
https://github.com/Laeeth/awslambda_d
http://blog.0x82.com/2014/11/24/aws-lambda-functions-in-go/
No proper docs yet, but you can figure it out from the go 
example.


https://aws.amazon.com/about-aws/whats-new/2015/10/aws-lambda-supports-python-versioning-scheduled-jobs-and-5-minute-functions/

Now runs functions taking up to 5 minutes.  Also Python tasks.  
(Already can run D - see above)

Re: Beta D 2.069.0-b1

[deadalnix via Digitalmars-d-announce]

On Saturday, 10 October 2015 at 02:57:03 UTC, Meta wrote:
On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak 
wrote:
That's what I meant, weird use-case, at best it's a callback 
better/setter.
I've never written such code, but even if you would, the 2 
pairs of parens are only a tiny problem for generic code, 
nothing to warrant the invasive language feature @property is.


I don't know how much metaprogramming-heavy generic code you've 
written, but I can say from first-hand experience that there is 
such a thing as Hell, and it is called Optional Parens.


Jokes aside, I've finally fixed (read: worked around using 
awful hacks) a bug where the compiler was complaining about 
either "Type.memberFunction is not callable with arguments ()" 
or "Need 'this' for Type.memberFunction". I love optional 
parens in regular code, especially range-based code (doesn't 
everybody?), but I desperately want a way to ensure that the 
symbol that I'm trying to pass to a template function won't be 
interpreted as a function call instead.


To the next person that is going to say this is overblown, I ran 
into such bugs more than once in phobos.


So, unless we expect most D developer to be better than phobos 
contributor, that is a problem.

Re: Beta D 2.069.0-b1

[deadalnix via Digitalmars-d-announce]

On Saturday, 10 October 2015 at 16:31:27 UTC, Ola Fosheim Grøstad 
wrote:
On Saturday, 10 October 2015 at 12:51:43 UTC, Jacob Carlborg 
wrote:
In Ruby, no one will ever use empty parentheses for calling a 
method.


That's actually the same as Simula. Functions/procedures with 
no parameters is called without parentheses.


That's actually quite beautiful in its simplicity.

Re: DIP74 - where is at?

[Freddy via Digitalmars-d]

On Sunday, 11 October 2015 at 04:16:11 UTC, deadalnix wrote:
The problem at hand is fairly well know at this stage: it is 
ownership. Everything else can be done as library.


This.

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

[Andrei Alexandrescu via Digitalmars-d]

On 10/10/15 9:06 PM, Eric Niebler wrote:

On Saturday, 10 October 2015 at 06:15:10 UTC, Andrei Alexandrescu wrote:

On 10/10/15 12:58 AM, Eric Niebler wrote:

To be honest, this whole conversation is kind of funny to me. It
reminds me of the Bugs Bunny cartoon where Marvin the Martian plants
his flag on Earth and says, "I claim this planet in the name of
[Digital] Mars!" We Earthlings respectfully disagree. :-)


Only it's the other way around, which makes the matter quite ironic.
You wrote:


P.S. I see lots of people here assuming that C++ is playing catch-up
to D because D has ranges and C++ doesn't yet. That is ignoring the
long history of ranges in C++. C++ got ranges in the form of the
Boost.Range library by Thorsten Ottoson sometime in the early 00's.
Andrei didn't implement D's ranges until many years after. The ranges
idea is older than dirt. It's not a D invention.


I think it would be a bit of a stretch to describe D ranges as
derivative of Boost ranges.


If I implied that I believe that D ranges were based on Boost.Range,
then I apologize. I don't believe that.


Well the simple fact is then that P.S. has done an awful job at 
conveying your point.



I suspect (but don't know) that
ranges in D were independently invented without knowledge of the long
history of them in C++.


Well that's easy to figure. "Iterators Must Go" at 
https://archive.org/details/AndreiAlexandrescuKeynoteBoostcon2009 
starting around minute 1:01:50 mentions "Ranges are not Boost ranges. 
They're very different". Same talk at 1:02:34 describes how Boost and 
Adobe defined their own ranges ("Boost and Adobe did make an interesting 
step in a good direction, however things must be taken way further than 
that." So there was knowledge of said long history of ranges in C++. Far 
as I can tell "Iterators Must Go" was immediately and universally 
recognized as a turning point in how people approached getting work done 
using ranges.


(Existing work I only found out recently: Matthew Wilson did define 
ranges as a generalization of D slices; his work was not based on C++ 
idioms, and made no inroads in the C++ community. His work _is_ strongly 
related to today's D ranges, I ought to have found that, and it is my 
mistake to not have.)



Which is fine except for the claims that C++ is
playing catch-up. It's not.


Anyhow, it's best for us all to focus on doing good work instead of
pettily fighting for irrelevant credit.


I only jumped in when I saw some disparagement of C++ and my work which
(IMO) was both
petty and wrong. I would very much like to drop this and get back to
productive work.


Eric, I don't know about others but I respect and like your work. I 
appreciate its originality, too. What I see here is a simple case when 
someone said something wrong and got his behind appropriately handed on 
a dish constructed of a precious metal.



Andrei

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

[deadalnix via Digitalmars-d]

On Saturday, 10 October 2015 at 18:07:02 UTC, Eric Niebler wrote:
If I implied that I believe that D ranges were based on 
Boost.Range, then I apologize. I don't believe that. I suspect 
(but don't know) that ranges in D were independently invented 
without knowledge of the long history of them in C++. Which is 
fine except for the claims that C++ is playing catch-up. It's 
not.




Ho come on, that's pretty obvious that C++ is playing catch up 
with all the new goodies there are in modern programming 
languages (which includes D, but not only). There is nothing 
wrong with it.


This is why the dev cycle went from eternity between 2 versions 
to few years. The talking point of the C++ inner circle has been 
super weird to say the least. It is like admitting it would be a 
supreme shame, while it is in fact the sign of a community that 
which to bring the best to its users, something nobody should be 
ashamed of.


Anyhow, it's best for us all to focus on doing good work 
instead of pettily fighting for irrelevant credit.


I only jumped in when I saw some disparagement of C++ and my 
work which (IMO) was both
petty and wrong. I would very much like to drop this and get 
back to productive work.


\e


This is where you get it wrong. Looking at what others are doing 
and adopting the good ideas is the characteristic of a language 
community that is focused on improving the language rather than 
participating in some ego battle.


There was no disparagement of your work as far as I can tell. The 
fact you choose to take it that way is what elicit this 
conversation in the first place.

Re: Beta D 2.069.0-b1

[deadalnix via Digitalmars-d-announce]

On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak wrote:
Right, ideally a @proptery function can perfectly replace a 
variable, but practically calling the return value seems far 
fetched.
What would you use that for, a handwritten interface struct 
with function pointers made read-only using @property?




It doesn't matter. If you want an explosion of special cases, 
there is already a language for that, it is called C++.


Every time an exception is introduced, the "burden of proof" is 
to prove this exception actually bring sufficient value to pay 
for itself, not the other way around.


To me the whole property discussion looks like one of those 
endless debates about an insignificant detail.

Scala and Ruby seem to do well with sloppy parens.


For what I've touched of ruby, the language is very permissive 
and nice. This is good when you do your first prototype, but this 
is also what causes it to be intractable at scale (and also 
impossible to optimize, but that is beside the point here).


Is the parentheses thing a problem ? Not really on its own, but 
it compound.


The parentheses thing and with it the special _ syntax to NOT 
call a function is not considered as a good thing by most scala 
people I've talked to.


With the introduction of UFCS it became clear that nobody likes 
byLine().array().sort().release(), and even less 
rng.release.sort().array().front.
For some functions it's really hard to decide whether or not 
something is a property, e.g. for me Range.save is an 
action/function not a property. So for me using @property 
appears to waste time making pointless decisions.


One can reach the desired effect by having a consistent set of 
rules and define the calling as a fallback rewrite when there is 
an error. Namely, add a rule that says : if this is an error, add 
() and retry. Here you go, problem solved, you can use 
parentheses function call in every places it is not ambiguous 
without introducing Byzantines set of rules into the language.

Re: DIP74 - where is at?

[deadalnix via Digitalmars-d]

On Sunday, 11 October 2015 at 01:48:05 UTC, Manu wrote:
I'm rather in favour of DIP74... what's unprincipled about it? 
What would you do instead?




Well, DIP25 and DIP74 are ad hoc adding to the language to 
support specific use cases. I think the whole thing is wrong 
headed.


Ideally when designing the language you want to have a set of 
principled tools added to the language that enable the uses cases 
you want. You don't bake the uses cases into the language. 
Inevitably, new use cases crop up, they get poor support and/or 
ends up as new addition into the language, with more and more 
complexity along the road.


The problem at hand is fairly well know at this stage: it is 
ownership. Everything else can be done as library.


The DIP25/DIP74 combo is quite limited. It doesn't solve 
ownership transfer, it forces an ownership model on the user, it 
doesn't reduce friction with the GC, it doesn't allow to delegate 
memory management to the user (the only kind that make sense). 
and worse, as these issue aren't orthogonal to these DIP, they 
actively make these problem harder to solve.


Solution have been proposed to solve these. It is not hardly new. 
I mean C++ obviously got the hint: 
https://github.com/isocpp/CppCoreGuidelines/blob/09aef9bd86d933bc1e1ffe344eb2e73d2de15685/docs/Lifetimes%20I%20and%20II%20-%20v0.9.1.pdf


If we go these DIP road, there is no coming back and this will 
get in the way of a principled approach.

Re: How to check whether an empty array variable is null?

[tcak via Digitalmars-d-learn]

On Saturday, 10 October 2015 at 20:07:11 UTC, Jonathan M Davis 
wrote:
On Saturday, October 10, 2015 15:20:02 tcak via 
Digitalmars-d-learn wrote:

[code]
  int[] list;

  list = new int[0];

  std.stdio.writeln("Is Null ? ", (list is null));
[/code]

Result is "Is Null? true".

Is this the correct behaviour? I would expect compiler to 
point to an address in the heap, but set the length as 0. So, 
it wouldn't return null, but the length would be 0 only.


It basically didn't bother to allocate an array on the heap, 
because you asked for one with a length of zero. 
Efficiency-wise, it makes no sense to allocate anything. You 
wouldn't be doing anything with the memory anyway. The only way 
that you're going to get an array of length 0 which doesn't 
have a null ptr is to slice an array down to a length of 0.


- Jonathan M Davis


The situation is that the "length" parameter comes from user. 
Also the item values come from user as well. I create the array 
with "length" parameter. At another part of code, I check firstly 
whether the array is created [code] if( array is null ) [/code], 
then the items are checked for validation.

Re: Compile time and runtime grammars

[Ali Çehreli via Digitalmars-d-learn]

On 10/10/2015 12:43 PM, H. S. Teoh via Digitalmars-d-learn wrote:
> On Sat, Oct 10, 2015 at 06:52:29PM +, DLangLearner via 
Digitalmars-d-learn wrote:


>> 1. There are confusing keywords:

To OP: I am glad that you are not bothered with compile-time foreach. ;)

> The "static" in "static if" is clear indication that this isn't a
> regular if-statement, but a branch that's taken at compile-time. I'm not
> sure how else it can be made clearer.

I would make curly brackets mandatory for the static if block and its 
else block. The following is almost always wrong:


static if (cond) {
// ...
} else if {// Oops! Inserting a run-time if
// ...
}

If that was really intended, they would have to use curly brackets:

} else {// <-- could be required
if {
// ...
}
}

Ali

Re: DIP74 - where is at?

[deadalnix via Digitalmars-d]

On Saturday, 10 October 2015 at 23:25:49 UTC, Manu wrote:
So I have another upcoming opportunity to introduce D in my 
workplace, this time as a front-end/plugin language to our C++ 
infrastructure, which is promising since I already have 
considerable experience in this area (my work at Remedy with 
Quantum Break), and there is a lot of recent work to interact 
better with C++, which we will stress-test extensively.


You only get so many shots at this; but this is a particularly 
promising opportunity, since the C++ code is a nightmare, and 
the contrast against D will allow a lot of coders to see the 
advantage.


There is however one critical missing feature, DIP74... where 
is it at currently? How is it going? Is it likely to be 
accepted in the near-term? Some sort of approximate timeline?


I think it would be a mistake for me to introduce this without 
DIP74, since we will rely on it VERY heavily, and the machinery 
to work-around it will start to look just as heavy-weight as 
the C++ code I'm trying to deprecate... but then waiting on it 
starts to look like missing the window of opportunity.


Thoughts?


It doesn't looks like it is getting implemented. And, to be 
honest, I'd rather go a principle approach + library support 
rather than a pie of hacks.


The pile of hacks approach is what made C++ C++.

Re: DIP74 - where is at?

[deadalnix via Digitalmars-d]

On Sunday, 11 October 2015 at 02:01:09 UTC, Jonathan M Davis 
wrote:
AFAIK, Walter and Andrei are still in favor of something that's 
at least similar to DIP 74. Andrei made a comment in a thread 
just the other day that indicated that he was in favor of 
having a way to build reference counting into classes. So, I 
don't know why you think that it's not going to be implemented 
other than the fact that it hasn't been implemented yet. It 
wouldn't surprise me if the DIP needed some tweaking though.




Yes, and that's quite ridiculous. I mean this is getting into 
ridiculous ego battle. Remind of that concept vs static if grand 
debate, the peak of ridiculousness (everybody know you don't need 
type system when you have if statement and vice versa, so the 
same must be true at compile time as well).


When a direction obviously showed to be the wrong one, the 
rational thing to do is not to double down in order to not admit 
one is wrong.


DIP25 implementation showed a ton of limitations and pitfalls. It 
isn't even possible to do a slice type with eager deallocation, 
just one with deferred deallocation, with complex strategies to 
make it all safe.


It is a sign of a poorly thought out language addition.

It wouldn't surprise me though if something like the 
possibility of getting D into another company relied on 
something like DIP 74 helped push it along and got it sorted 
out faster. Clearly, Walter and Andrei think that it's an issue 
and have done some work on it at the theoretical level, but I 
don't know where it sits on their priority list. And even if 
DIP 74 were fully sorted out tomorrow, it would still require 
Walter or someone else actually implementing it, and that's 
probably not a small undertaking.


- Jonathan M Davis


Yeah, we saw what happens with attributes. Don't get me wrong, 
attribute are a very useful addition to the language and all, but 
the current implementation has some serious flaws, none of them 
could be addressed as it was pushed out of the door in an 
inconsequent manner. The fact that dlang.org is littered of 
antipaterns usage of them is quite telling.


I'm all for pushing useful feature, especially if that can drive 
adoption in a company. But using it as an excuse for releasing 
half backed feature is VERY short sighted.

Re: -> and :: operators

[Walter Bright via Digitalmars-d]

On 10/9/2015 12:48 PM, Dmitry Olshansky wrote:

On 09-Oct-2015 21:44, Freddy wrote:

Stole from D? You mean java right?


There is no value type objects in Java so no. More likely C#.


Since C# was an internal Microsoft project at the time this was 
developed for D, no.

Re: DIP74 - where is at?

[Jonathan M Davis via Digitalmars-d]

On Sunday, 11 October 2015 at 04:56:25 UTC, deadalnix wrote:
On Sunday, 11 October 2015 at 04:35:03 UTC, Jonathan M Davis 
wrote:

On Sunday, 11 October 2015 at 04:16:11 UTC, deadalnix wrote:
If we go these DIP road, there is no coming back and this 
will get in the way of a principled approach.


Then come up with an alternative DIP which shows a better way 
to solve this. As it stands, it looks likely that we'll end up 
with some form of DIP 74, and if you have a better proposal, 
then now is probably the time to do it.




I have, other have as well, in fact there was a lengthy 
discussion in private between Walter, Andrei, myself and some 
other where very precise proposal has been made.


I'm sorry but that's bullshit. I'm tired of reexplaining the 
same thing again and again while is it clear that nobody cares 
about facts here. If people would care about facts, the DIP25 
fiasco would have been enough to put the ideas back on the 
table.


Well, if they won't listen, they won't listen. And if they're 
wrong, we'll be worse off for it. Unfortunately, I wasn't 
involved in those discussions and haven't looked into DIP 25 much 
(I was too busy at the time of the major discussion for it IIRC). 
So, I'm not familiar enough with it to have a properly informed 
opinion. But convincing Walter and Andrei is typically pretty 
difficult. They do come around eventually at least some of the 
time though. So, as frustrating as such discussions can be, they 
do bear fruit at least some of the time (whether it's by them 
convincing you or by you convincing them). And since DIP 25 has 
only been implemented with a flag rather than adding it to the 
language proper yet, there's still time to convince them before 
we're fully committed to it - as difficult as convincing them may 
be.


- Jonathan M Davis

Re: Categorizing Ranges

[Joseph Rushton Wakeling via Digitalmars-d]

On Wednesday, 7 October 2015 at 15:39:03 UTC, Jonathan M Davis 
wrote:
Eager is far more general. Also, while the drop* functions are 
eager, the take* functions are not.


I don't recall the precise details of these particular ranges off 
the top of my head (away from computer so can't easily check), 
but one nasty little detail of supposedly lazy ranges is that 
they are often eager for the first element, lazy thereafter -- 
and even there it's subtly different from 'true' laziness 
inasmuch as the new values are generated at the point of popping 
rather than the point of access to the new front.


In most cases that's an implementation detail, but it gets _very_ 
interesting when the elements of your range are non-deterministic.

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

[Andrei Alexandrescu via Digitalmars-d]

On 10/10/15 12:58 AM, Eric Niebler wrote:

To be honest, this whole conversation is kind of funny to me. It
reminds me of the Bugs Bunny cartoon where Marvin the Martian plants
his flag on Earth and says, "I claim this planet in the name of
[Digital] Mars!" We Earthlings respectfully disagree. :-)


Only it's the other way around, which makes the matter quite ironic. You 
wrote:



P.S. I see lots of people here assuming that C++ is playing catch-up
to D because D has ranges and C++ doesn't yet. That is ignoring the
long history of ranges in C++. C++ got ranges in the form of the
Boost.Range library by Thorsten Ottoson sometime in the early 00's.
Andrei didn't implement D's ranges until many years after. The ranges
idea is older than dirt. It's not a D invention.


I think it would be a bit of a stretch to describe D ranges as 
derivative of Boost ranges.


Anyhow, it's best for us all to focus on doing good work instead of 
pettily fighting for irrelevant credit.



Andrei

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

[Andrei Alexandrescu via Digitalmars-d]

On 10/10/15 12:58 AM, Eric Niebler wrote:

Trying to express algorithms without any clear abstraction of "position
within range" (independent of ranges) is hard and awkward, and
occasionally causes algorithms to be less efficient.


I agree that ranges are a weaker basis than iterators. But it's not 
necessarily that a notion of position is the only way out.


Ranges can be made as strong a basis by adding the O(1) primitives 
r1.before(r2) and r1.after(r2) that return the prefix/suffix following 
r2 within r1. With those I hope to be able to show easily that 
algorithms needing "iterator in the middle" can be redone.


I think I need to sit down and define these primitives (albeit they 
aren't used that frequently) and use them in a few fundamental 
algorithms to just close the matter once and for all.



Andrei

[Issue 9800] Numerous issues with DWARF debug output

[via Digitalmars-d-bugs]

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

--- Comment #12 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #2)
> 
> 7. DW_TAG_module is only valid for Fortran/Modula-2, but I'd argue that this
> is a bug.  It would be nice to represent statics as being part of a module,
> my hope would be that adding support would mean that we'd no longer have to
> use 'quotations' or the full mangled name to get/set global decls in the
> debugger.  Though it is worth noting that DWARF2 does not have DW_TAG_module.
> 
> 

The next version of GDB (7.11, unless they do some bikeshedding of their
versioning system) will include explicit support for this in D programs.  And
will also be able to discover if a bare named symbol is from an imported
module, and even handles renamed module + symbol imports.

However it still requires that DMD be able to emit debug code for this though.

--

[Issue 9800] Numerous issues with DWARF debug output

[via Digitalmars-d-bugs]

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

--- Comment #13 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #1)
> I'll post this in a few parts for ease of taking in, starting with the TL;DR.
> 
> It is evident that dmd needs some loving on it's side, but I'll weigh in my
> thoughts on behalf of gdc's implementation here:
> 
> From what you have raised, this is the current state of play (in gdc)
> 
> Fixed Bugs: #1 (with limitation to integral types), #9
> Identified Bugs: #7, #8, #10

These three identified bugs have been fixed in gdc+gdb.

--

[Issue 15180] [REG2.069.0-b1] Segfault with empty struct used as UDA

[via Digitalmars-d-bugs]

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

--- Comment #5 from Jacob Carlborg  ---
https://github.com/D-Programming-Language/dmd/pull/5181

--

Re: Beta D 2.069.0-b1

[Jacob Carlborg via Digitalmars-d-announce]

On 2015-10-10 03:52, Martin Nowak wrote:


Scala and Ruby seem to do well with sloppy parens.


A few notes about why Ruby doesn't have the same problems as D has:

1. Ruby has optional parentheses for all method calls, regardless if 
they accept arguments or not


2. Ruby has a different syntax for calling lambdas from calling functions:

def foo
end

foo() # calling function

a = -> { }
a.call # calling lambda
a.() # alternative syntax for calling lambda

In Ruby, no one will ever use empty parentheses for calling a method.

3. You can not use the setter syntax for a "regular" method taking one 
argument:


class Foo
  def bar(a)
  end

  def foo=(a) # not the same name as "foo"
  end
end

a = Foo.new
a.bar = 3 # error
a.foo = 3 # ok
a.foo(3) # error

--
/Jacob Carlborg