Greetings,
I need to match any character, except control characters and some
other exceptions and thought this would be a good usecase to use
character classes and set operations.
Can I combine this with unicode properties?, e.g: any Charactor
that is not a control character and not ';' or '
I prefer the built-in associative array over using some template
library. It has the clean look and ease-of-use that you get with
a similar data structure in dynamic languages like Python. I
consider it a top feature of D.
Sorry for dig out this posting, but this one is more recent, than
http://forum.dlang.org/thread/k15of5$22ub$1...@digitalmars.com?page=1
and my question is just beyond the two:
I'm with you, regarding that the standard init property should
not be overridden. But how about to override it with a
On 10/30/17 6:49 AM, Tony wrote:
I prefer the built-in associative array over using some template
library. It has the clean look and ease-of-use that you get with a
similar data structure in dynamic languages like Python. I consider it a
top feature of D.
There is a misunderstanding here. The
On 10/30/17 6:59 AM, Alex wrote:
Sorry for dig out this posting, but this one is more recent, than
http://forum.dlang.org/thread/k15of5$22ub$1...@digitalmars.com?page=1
and my question is just beyond the two:
I'm with you, regarding that the standard init property should not be
overridden. Bu
On Monday, 30 October 2017 at 15:03:25 UTC, Steven Schveighoffer
wrote:
This should also be disallowed. In order to know x.init means
what it normally means, we shouldn't allow overriding it. This
is the point of this thread, and the impetus for renaming of
TypeInfo.init().
Yeah... my prob
On Sunday, 29 October 2017 at 15:45:23 UTC, Jesse Phillips wrote:
Not really you'll need to parse it out as a string and do the
conversion later.
It probably would be good to support nullable!int pretty sure
it doesn't currently.
Should I raise a ticket on Bugzilla to address this?
On 10/30/17 11:39 AM, Alex wrote:
On Monday, 30 October 2017 at 15:03:25 UTC, Steven Schveighoffer wrote:
This should also be disallowed. In order to know x.init means what it
normally means, we shouldn't allow overriding it. This is the point of
this thread, and the impetus for renaming of T
The following code assert fails (bar == 1, not -10!). I've wasted
a bit of time because of this happening.
void main() {
if (int bar = foo() != 0) {
assert(bar == -10);
}
}
auto foo() {
return -10;
}
On Tuesday, October 31, 2017 04:08:12 Joel via Digitalmars-d-learn wrote:
> The following code assert fails (bar == 1, not -10!). I've wasted
> a bit of time because of this happening.
>
> void main() {
> if (int bar = foo() != 0) {
> assert(bar == -10);
> }
> }
>
> auto foo() {
> retur
On Tuesday, 31 October 2017 at 04:08:12 UTC, Joel wrote:
if (int bar = foo() != 0) {
Not a bug, but I do think it is an iffy design.
That is more like:
int bar;
if(bar = (foo() != 0))
so the foo != 0 is evaluated first, which ends up being boolean
true or false, then THAT true/false
Ok, thanks guys.
On Tuesday, 31 October 2017 at 04:27:27 UTC, Joel wrote:
Ok, thanks guys.
why not throw in some UFCS too...just because you can ;-)
import std.stdio;
void main()
{
int foo;
if (foo.bar != 0) // would be nice if I could do: (int
foo.bar != 0)
{
throw new Exception("foo.b
13 matches
Mail list logo
