On Friday, 22 November 2013 at 07:37:11 UTC, Kenji Hara wrote:
2013/11/22 deadalnix
On Friday, 22 November 2013 at 04:33:56 UTC, Kenji Hara wrote:
After removing 'function' concept, 'func' always means
function pointer or
delegate. So we cannot call functions without parenthesis
anymore. It
On Thursday, 21 November 2013 at 21:36:28 UTC, Andrei
Alexandrescu wrote:
On 11/21/13 1:16 PM, Gary Willoughby wrote:
On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei
Alexandrescu wrote:
Fortunately a lot has changed since :o).
Please, do tell. ;)
Not much that people don't know alread
On Friday, 22 November 2013 at 07:37:11 UTC, Kenji Hara wrote:
2013/11/22 deadalnix
On Friday, 22 November 2013 at 04:33:56 UTC, Kenji Hara wrote:
After removing 'function' concept, 'func' always means
function pointer or
delegate. So we cannot call functions without parenthesis
anymore. It
On 2013-11-22 01:17, Shammah Chancellor wrote:
Additionally, I left active participation in the D community about five
years ago due to life circumstances -- and only recently rejoined. I am
not familiar with the DIP procedures.
DIP - D Improvement Proposal. Just look at the other ones to get
2013/11/22 deadalnix
> On Friday, 22 November 2013 at 04:33:56 UTC, Kenji Hara wrote:
>
>> After removing 'function' concept, 'func' always means function pointer or
>> delegate. So we cannot call functions without parenthesis anymore. It is
>> unacceptable change to me, and many D programmers wo
On Thursday, November 21, 2013 20:17:34 Walter Bright wrote:
> On 11/20/2013 11:51 PM, Jacob Carlborg wrote:
> > On 2013-11-21 07:06, Walter Bright wrote:
> >> The next release is going to be about bug fixes, not introducing
> >> regressions from new features(!). It's a short release cycle, anyway.
On Friday, 22 November 2013 at 00:50:25 UTC, John J wrote:
On 11/21/2013 02:20 PM, monarch_dodra wrote:
When you import from a module, you only need to specify the
module name
if there is ambiguity. So for example:
//
import std.array;
void main()
{
split("hello"); //OK!
}
//
im
On Friday, 22 November 2013 at 04:33:56 UTC, Kenji Hara wrote:
After removing 'function' concept, 'func' always means function
pointer or
delegate. So we cannot call functions without parenthesis
anymore. It is
unacceptable change to me, and many D programmers would
probably argue same
thing.
2013/11/22 deadalnix
> On Friday, 22 November 2013 at 01:33:44 UTC, Kenji Hara wrote:
>
>> At least to me, your argument is just to return to the C era. I think it
>> will introduce huge 'regression'.
>>
>>
> This is an important misunderstanding of my position. The C era is bad,
> the D era is k
On 11/20/2013 11:51 PM, Jacob Carlborg wrote:
On 2013-11-21 07:06, Walter Bright wrote:
The next release is going to be about bug fixes, not introducing
regressions from new features(!). It's a short release cycle, anyway.
You better watch what happens deep inside the pull requests then :)
On Friday, 22 November 2013 at 01:33:44 UTC, Kenji Hara wrote:
2013/11/22 deadalnix
Why do we make the distinction between a first class function
and a
function in the first place ?
(This is just my recognition, so might be not same with true
history. But I
think there's not so big mist
Today, I went back to one of my earlier D projects and recompiled it
with the latest dmd toolchain, and ran into this regression:
https://d.puremagic.com/issues/show_bug.cgi?id=11576
Fortunately, I was ticked off enough about this to actually dig into the
Phobos code to figure out what's
On Friday, 22 November 2013 at 02:35:40 UTC, Shammah Chancellor
wrote:
void someFunc() // nothrow
{
scope(failure) { writeln("What?");} <-- NEVER EXECUTED?!
scope(failure) {
writeln("Failed in someFunc()");
return;
}
throwingFunction();
}
That does exactly as expe
On Friday, 22 November 2013 at 02:17:18 UTC, Andrei Alexandrescu
wrote:
On 11/21/13 6:07 PM, growler wrote:
On Friday, 22 November 2013 at 01:49:11 UTC, Shammah
Chancellor wrote:
On 2013-11-18 06:32:46 +, Andrei Alexandrescu said:
1. Fix scope(failure) and then use it.
Andrei
Huh? Sco
On Friday, 22 November 2013 at 02:35:40 UTC, Shammah Chancellor
wrote:
...
What!? That shouldn't even be legal code! See below for why:
...
Maybe that's why it is considered broken? The first point was to
'fix' scope(failure) and then use it.
However, I don't know I haven't been fol
On Friday, 22 November 2013 at 02:25:22 UTC, SomeDude wrote:
That is because Go doesn't force anyone to think about design.
The only design-level construct it has is the class an that's
it.
That actually makes it a good first language to learn
programming (and also bad programming). Simplicit
On 2013-11-22 02:07:36 +, growler said:
On Friday, 22 November 2013 at 01:49:11 UTC, Shammah Chancellor wrote:
On 2013-11-18 06:32:46 +, Andrei Alexandrescu said:
1. Fix scope(failure) and then use it.
Andrei
Huh? Scope failure has no purpose here. It does not CATCH the
exceptio
On Thursday, 21 November 2013 at 09:33:04 UTC, Bienlein wrote:
What puzzles me is the enormous activity in the Go forum. Only
the Python forum has that much traffic. It seems to me that
people are all that happy if they have a language with which
they
can just start hacking around on something.
On 11/21/13 6:07 PM, growler wrote:
On Friday, 22 November 2013 at 01:49:11 UTC, Shammah Chancellor wrote:
On 2013-11-18 06:32:46 +, Andrei Alexandrescu said:
1. Fix scope(failure) and then use it.
Andrei
Huh? Scope failure has no purpose here. It does not CATCH the
exception and prev
On Friday, 22 November 2013 at 01:49:11 UTC, Shammah Chancellor
wrote:
On 2013-11-18 06:32:46 +, Andrei Alexandrescu said:
1. Fix scope(failure) and then use it.
Andrei
Huh? Scope failure has no purpose here. It does not CATCH the
exception and prevent it from bubbling up the call cha
On Friday, 22 November 2013 at 01:49:11 UTC, Shammah Chancellor
wrote:
On 2013-11-18 06:32:46 +, Andrei Alexandrescu said:
1. Fix scope(failure) and then use it.
Andrei
Huh? Scope failure has no purpose here. It does not CATCH the
exception and prevent it from bubbling up the call cha
On 22.11.2013 00:50, Meta wrote:
On Thursday, 21 November 2013 at 22:51:43 UTC, inout wrote:
What if you have more that just one validation, e.g. Positive and
LessThan42?
Is Positive!LessThan42!int the same type as LessThan42!Positive!int?
Implicitly convertible?
Allow multiple validation func
On 2013-11-18 06:32:46 +, Andrei Alexandrescu said:
1. Fix scope(failure) and then use it.
Andrei
Huh? Scope failure has no purpose here. It does not CATCH the
exception and prevent it from bubbling up the call chain.Try/catch
does do this.
-Shammah
On 2013-11-21 22:17:05 +, bearophile said:
Andrei Alexandrescu:
At this point focusing on making D solid and reliable is the best thing to do.
At this point what's important is to perform the small breaking changes
that are left to do (and deprecate what needs to be deprecated),
becaus
2013/11/22 deadalnix
>
> Why do we make the distinction between a first class function and a
> function in the first place ?
>
(This is just my recognition, so might be not same with true history. But I
think there's not so big mistake.)
Historically, mixing function themselves and function addr
On 11/21/2013 01:36 PM, Steve Teale wrote:
I thought that compilers were supposed to help you if you did ambiguous
things. An interesting example is:
int bar(int n)
{
return n+1;
}
int bar(int n)
{
return n+2;
}
void main()
{
int v = 22;
int n = bar(22);
}
Compiler helps her
On 11/21/2013 02:20 PM, monarch_dodra wrote:
When you import from a module, you only need to specify the module name
if there is ambiguity. So for example:
//
import std.array;
void main()
{
split("hello"); //OK!
}
//
import std.array;
import std.algorithm;
void main()
{
spl
On Thursday, 21 November 2013 at 23:31:18 UTC, Andrei
Alexandrescu wrote:
On 11/21/13 3:18 PM, deadalnix wrote:
Why do we make the distinction between a first class function
and a
function in the first place ?
C and C++ and PHP are the only languages I know that do that.
That is
quite tellin
On 11/21/2013 02:20 PM, monarch_dodra wrote:
When you import from a module, you only need to specify the module name
if there is ambiguity. So for example:
//
import std.array;
void main()
{
split("hello"); //OK!
}
//
import std.array;
import std.algorithm;
void main()
{
spli
On 2013-11-21 16:13:31 +, Dejan Lekic said:
Having this in phobos would be really helpful! If there is interest
in this, I'll write a template up and submit it to phobos.
-Shammah
Why not simply make your own repo somewhere (Gitorious, GitHub,
Savannah, etc) and once you are done j
On 2013-11-21 19:30:00 +, Andrei Alexandrescu said:
On 11/21/13 10:45 AM, Jacob Carlborg wrote:
On 2013-11-21 17:02, Andrei Alexandrescu wrote:
Interfaces can't check for a variety of things that Boolean conditions
can (isInfinite comes to mind).
Why wouldn't you be able to put the impl
On Thursday, 21 November 2013 at 22:51:43 UTC, inout wrote:
What if you have more that just one validation, e.g. Positive
and LessThan42?
Is Positive!LessThan42!int the same type as
LessThan42!Positive!int? Implicitly convertible?
Allow multiple validation functions. Then a Validated type is
On 11/21/13 3:18 PM, deadalnix wrote:
Why do we make the distinction between a first class function and a
function in the first place ?
C and C++ and PHP are the only languages I know that do that. That is
quite telling on how good the idea is.
All three wildly successful :o).
Andrei
On Thursday, 21 November 2013 at 14:11:54 UTC, John Colvin wrote:
On Thursday, 21 November 2013 at 13:28:01 UTC, Timon Gehr wrote:
On 11/21/2013 02:04 PM, John Colvin wrote:
3) properties decay to normal functions when they have their
address taken
No, why?
Sorry, I forgot to add:
5) par
On Thursday, 21 November 2013 at 21:36:28 UTC, Andrei
Alexandrescu wrote:
On 11/21/13 1:16 PM, Gary Willoughby wrote:
On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei
Alexandrescu wrote:
Fortunately a lot has changed since :o).
Please, do tell. ;)
Not much that people don't know alread
On Wednesday, 20 November 2013 at 17:45:43 UTC, Simen Kjærås
wrote:
On 20.11.2013 12:49, Jacob Carlborg wrote:
On 2013-11-20 12:16, Jonathan M Davis wrote:
You'd do it the other way around by having something like
ValidatedString!char s = validateString("hello world");
Right.
ValidatedStri
Andrei Alexandrescu:
At this point focusing on making D solid and reliable is the
best thing to do.
At this point what's important is to perform the small breaking
changes that are left to do (and deprecate what needs to be
deprecated), because doing that even later will be a problem.
Bye,
On 11/21/13 1:16 PM, Gary Willoughby wrote:
On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei Alexandrescu wrote:
Fortunately a lot has changed since :o).
Please, do tell. ;)
Not much that people don't know already. We have one solid D project
installed and a couple of heavy-hitting eng
On 2013-11-21 18:18, Joshua Niehus wrote:
On Thursday, 21 November 2013 at 13:56:07 UTC, Jacob Carlborg wrote:
BTW, if you're able to figure out how to build the Mac OS X installer
on Linux Walter would appreciate it. I failed to do that.
this might help:
https://github.com/hogliux/bomutils
On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei
Alexandrescu wrote:
Fortunately a lot has changed since :o).
Please, do tell. ;)
On 11/18/2013 11:41 AM, Iain Buclaw wrote:
Hi,
I've created a gdb fork on github and will be giving d-lang support some
love - with the intention of pushing patches back to gdb development as
soon as possible. The bulk of the work will be done over the next
fortnight, but for some other work (s
On 11/21/13, 7:23 AM, Jacob Carlborg wrote:
On 2013-11-21 12:17, Andrew Edwards wrote:
Have you seen this:
I have.
https://github.com/D-Programming-Language/installer/pull/24
Also we already have a script that creates an installer for Mac OS X:
https://github.com/D-Programming-Language/i
On Thursday, 21 November 2013 at 03:14:30 UTC, Manu wrote:
It would be nice to have a commitment on @property.
Currently, () is optional on all functions, and @property means
nothing.
I personally think () should not be optional, and @property
should require
that () is not present (ie, @proper
On 11/20/13 11:50 PM, Jacob Carlborg wrote:
I guess his suggestion would be something like this:
interface InputRange (R)
{
@property bool empty ();
void popFront ();
ElementType!(R) front ();
}
void foo (R) (R r) if(implements!(InputRange!(R)))
Interfaces can't check for a var
On 2013-11-21 13:43, Andrew Edwards wrote:
I have.
So, why don't you use that instead of creating a completely new script?
I've looked at this. But what we have assumes that there is already a
zip file present, fetches the zip and from that generates the an
installer. My understanding is tha
On 11/21/2013 02:04 PM, John Colvin wrote:
3) properties decay to normal functions when they have their address taken
No, why?
On 11/21/2013 03:26 PM, John Colvin wrote:
On Thursday, 21 November 2013 at 14:19:22 UTC, Wyatt wrote:
On Thursday, 21 November 2013 at 13:04:21 UTC, John Colvin wrote:
3) properties decay to normal functions when they have their address
taken
Is there some reason why we _need_ to be able to
On Thursday, 21 November 2013 at 07:44:44 UTC, Jonathan M Davis
wrote:
As I understand it, when Walter is talking about a validator
function, _all_
it does is validate the input. It doesn't operate on the data
beyond doing validation
I doubt Walter first checks that a file is a valid D program
On 11/20/2013 10:35 PM, Jonathan M Davis wrote:
Definitely, but almost all arguments over coding style seem to be very
subjective even when some people try and claim that some of the issues are
objective.
I've run across actual research on aspects of this now and then, and real
measurable stat
On Thursday, 21 November 2013 at 07:22:39 UTC, Steve Teale wrote:
import std.stdio;
enum Intention
{
EVIL,
NEUTRAL,
GOOD,
SAINTLY
}
void foo(Intention rth)
{
if (rth == EVIL)
writeln("Road to hell");
}
void main()
{
foo(EVIL);
}
Why does the compiler complain in both
On 11/21/13 10:45 AM, Jacob Carlborg wrote:
On 2013-11-21 17:02, Andrei Alexandrescu wrote:
Interfaces can't check for a variety of things that Boolean conditions
can (isInfinite comes to mind).
Why wouldn't you be able to put the implementation of isInfinite in an
interface?
It's a value,
On Thursday, 21 November 2013 at 18:44:39 UTC, Steve Teale wrote:
On Thursday, 21 November 2013 at 17:39:28 UTC, Andrei
Alexandrescu wrote:
On 11/21/13 8:48 AM, Steve Teale wrote:
Could 'with' be extended to cover enum names do you think?
Also a
supplementary question - does auto lock out some
On Thursday, 21 November 2013 at 08:05:03 UTC, Michal Minich
wrote:
On Thursday, 21 November 2013 at 07:42:48 UTC, Craig Dillabaugh
wrote:
I should also mention, this post likely better belongs in:
digitalmars.D.learn
I don't entirely think so. I think the OP is arguing that D
should be able
On Thursday, 21 November 2013 at 14:19:22 UTC, Wyatt wrote:
On Thursday, 21 November 2013 at 13:04:21 UTC, John Colvin
wrote:
3) properties decay to normal functions when they have their
address taken
Is there some reason why we _need_ to be able to take the
address of properties? I've yet t
On Thursday, 21 November 2013 at 15:25:21 UTC, eles wrote:
On Thursday, 21 November 2013 at 13:28:01 UTC, Timon Gehr wrote:
On 11/21/2013 02:04 PM, John Colvin wrote:
3) properties decay to normal functions when they have their
address taken
No, why?
properties should be just "variables
On Thursday, 21 November 2013 at 12:14:09 UTC, Paulo Pinto wrote:
On Thursday, 21 November 2013 at 11:07:15 UTC, Chris wrote:
On Thursday, 21 November 2013 at 09:57:35 UTC, Bienlein wrote:
On Thursday, 21 November 2013 at 09:33:04 UTC, Bienlein wrote:
What puzzles me is the enormous activity in
On Thursday, 21 November 2013 at 13:28:01 UTC, Timon Gehr wrote:
On 11/21/2013 02:04 PM, John Colvin wrote:
3) properties decay to normal functions when they have their
address taken
No, why?
properties should be just "variables without address". that is,
taking the address of a property
That should be:
if( rth == Intention.EVIL ) and
foo( Intention.EVIL );
Phobos is less picky than the compiler. Try this:
import std.stdio;
enum Intention
{
EVIL,
NEUTRAL,
GOOD,
SAINTLY
}
void foo(Intention rth)
{
if (rth == Intention.EVIL)
writefln("The road to hell is
On Thursday, 21 November 2013 at 14:19:22 UTC, Wyatt wrote:
On Thursday, 21 November 2013 at 13:04:21 UTC, John Colvin
wrote:
3) properties decay to normal functions when they have their
address taken
Is there some reason why we _need_ to be able to take the
address of properties? I've yet t
On Thursday, 21 November 2013 at 17:19:18 UTC, inout wrote:
On Thursday, 21 November 2013 at 07:22:39 UTC, Steve Teale
wrote:
import std.stdio;
enum Intention
{
EVIL,
NEUTRAL,
GOOD,
SAINTLY
}
void foo(Intention rth)
{
if (rth == EVIL)
writeln("Road to hell");
}
void main()
{
On Thursday, November 21, 2013 16:38:48 Jesse Phillips wrote:
> On Thursday, 21 November 2013 at 07:44:44 UTC, Jonathan M Davis
>
> wrote:
> > As I understand it, when Walter is talking about a validator
> > function, _all_
> > it does is validate the input. It doesn't operate on the data
> > beyo
On 2013-11-21 17:02, Andrei Alexandrescu wrote:
Interfaces can't check for a variety of things that Boolean conditions
can (isInfinite comes to mind).
Why wouldn't you be able to put the implementation of isInfinite in an
interface? I might no be any advantage over a template like it is now,
BOOM! Code no longer compiles.
As a rule, the code that compiles and works should preserve
its behavior when new code is added, so this is prohibited.
Also please post to D.learn
forgot to add:
void foo(OtherIntention rth) { ... }
Which of the two is being called by main?
I thought that
On Thursday, 21 November 2013 at 17:39:28 UTC, Andrei
Alexandrescu wrote:
On 11/21/13 8:48 AM, Steve Teale wrote:
Could 'with' be extended to cover enum names do you think?
Also a
supplementary question - does auto lock out some things like
this, are
there other examples?
Guess it could. One
On 2013-11-21 12:17, Andrew Edwards wrote:
That is good but we will be building from a branch when it's time to
prepare the binaries. Or do we first prepare the binaries then branch?
They should be built from a branch.
Any idea how I access and run the auto tester from my machine? I've
tried
On Thursday, 21 November 2013 at 07:50:11 UTC, Jacob Carlborg
wrote:
I guess his suggestion would be something like this:
interface InputRange (R)
{
@property bool empty ();
void popFront ();
ElementType!(R) front ();
}
void foo (R) (R r) if(implements!(InputRange!(R)))
Personally
On Thursday, 21 November 2013 at 17:39:28 UTC, Andrei
Alexandrescu wrote:
On 11/21/13 8:48 AM, Steve Teale wrote:
Could 'with' be extended to cover enum names do you think?
Also a
supplementary question - does auto lock out some things like
this, are
there other examples?
Guess it could. One
On Thursday, 21 November 2013 at 13:56:07 UTC, Jacob Carlborg
wrote:
BTW, if you're able to figure out how to build the Mac OS X
installer on Linux Walter would appreciate it. I failed to do
that.
this might help:
https://github.com/hogliux/bomutils
On Thursday, 21 November 2013 at 16:48:59 UTC, Steve Teale wrote:
Could 'with' be extended to cover enum names do you think? Also
a supplementary question - does auto lock out some things like
this, are there other examples?
Is this what you mean?
enum Intention
{
EVIL,
NEUTRA
Having this in phobos would be really helpful! If there is
interest in this, I'll write a template up and submit it to
phobos.
-Shammah
Why not simply make your own repo somewhere (Gitorious, GitHub,
Savannah, etc) and once you are done just announce it at here so
we can try it? Or, alt
On Thursday, 21 November 2013 at 03:15:16 UTC, Walter Bright
wrote:
On 11/20/2013 5:45 PM, Andrei Alexandrescu wrote:
In this context "objectively worse" means "all reasonable
people would say it's
worse".
It could also be objectively measured as:
1. results in more bugs
2. takes people lon
On Thursday, 21 November 2013 at 13:28:01 UTC, Timon Gehr wrote:
On 11/21/2013 02:04 PM, John Colvin wrote:
3) properties decay to normal functions when they have their
address taken
No, why?
Sorry, I forgot to add:
5) parenthesis are enforced for all calls on all callables other
than fu
On Thursday, 21 November 2013 at 13:04:21 UTC, John Colvin wrote:
3) properties decay to normal functions when they have their
address taken
Is there some reason why we _need_ to be able to take the address
of properties? I've yet to see a good argument in favour of it,
and I've seen several
On Monday, 18 November 2013 at 23:55:50 UTC, Stretto wrote:
F# now has Discriminated Unions:
http://msdn.microsoft.com/en-US/library/dd233226.aspx
Would it be possible to have something similar in D?
...I was thinking more of a built in way to do this but I guess
these solutions will do.
On Wednesday, 20 November 2013 at 18:30:58 UTC, Dmitry Olshansky
wrote:
And it decays to the naked type in a blink of an eye. And some
function down the road will do the validation again...
Not if that function down the road only accepted validated in the
first place because that is what i
On Thursday, 21 November 2013 at 13:04:21 UTC, John Colvin wrote:
On Thursday, 21 November 2013 at 03:14:30 UTC, Manu wrote:
It would be nice to have a commitment on @property.
Currently, () is optional on all functions, and @property
means nothing.
I personally think () should not be optional,
On 11/21/2013 6:10 AM, Dicebot wrote:
You need to prove first that it results in more bugs because of inherent code
style traits, not preferences of target audience.
You're saying that human factors engineering is purely a matter of personal
preference. IT IS NOT. The way the mind works is not
On 11/21/13 7:31 AM, Chris wrote:
Luckily we can now point to Facebook as possible corporate sponsor.
But that's post-factum. The language already happily exists outside the
corporate sphere, unlike Java that was a product from the very beginning.
Each language has its story, but it's undenia
On 11/21/13 8:48 AM, Steve Teale wrote:
Could 'with' be extended to cover enum names do you think? Also a
supplementary question - does auto lock out some things like this, are
there other examples?
Guess it could. One other thing we could do is to make enum namespaces
behave like imports.
A
On Thursday, 21 November 2013 at 08:37:32 UTC, Craig Dillabaugh
wrote:
Yes, perhaps that was his intention (no pun intended). First few
times I used enums in D I was caught because I expected the
behavior he is suggesting here would work.
Pun was intended ;=)
On Thursday, 21 November 2013 at 11:07:15 UTC, Chris wrote:
On Thursday, 21 November 2013 at 09:57:35 UTC, Bienlein wrote:
On Thursday, 21 November 2013 at 09:33:04 UTC, Bienlein wrote:
What puzzles me is the enormous activity in the Go forum. Only
the Python forum has that much traffic. It see
On 2013-11-21 08:38, Jacob Carlborg wrote:
On 2013-11-21 01:16, Simen Kjærås wrote:
The result of re-validating is performance loss. The result of missed
validation is a bug. Also, in just a few lines, you can make a version
that will *not* decay to the original type:
struct Validated(alias
On 11/21/13, 6:17 AM, Andrew Edwards wrote:
Any idea how I access and run the auto tester from my machine? I've
tried contacting Brad Anderson but no response. Maybe I had the wrong
email address.
Messed that up... I meant Brad Roberts.
On 11/18/13, 3:13 AM, Jacob Carlborg wrote:
On 2013-11-17 17:32, Andrew Edwards wrote:
I have couple issues remaining for Mac OS X that I'm hoping you can
provide some clarification on:
1) The install option for TOOLS, unlike DMD, DRUNTIME or PHOBOS attempts
to install the generated binaries d
On Thursday, 21 November 2013 at 03:10:17 UTC, Walter Bright
wrote:
...
The solution was to replace the horn's siren with a voice
saying what was wrong, such as "fire engine no. 2" and "pull
up". This worked BETTER.
I see no difference with coding styles. Some are better, some
are worse. As
On Thursday, 21 November 2013 at 09:57:35 UTC, Bienlein wrote:
On Thursday, 21 November 2013 at 09:33:04 UTC, Bienlein wrote:
What puzzles me is the enormous activity in the Go forum. Only
the Python forum has that much traffic. It seems to me that
people are all that happy if they have a langua
> According to TDPL (§2.2.6, p.40), the type of array literals are
> inferred by applying the ?: operator to elements pairwise. But the
> second call to func() above fails in spite of the fact that this code
> passes:
https://d.puremagic.com/issues/show_bug.cgi?id=5498
On Thursday, 21 November 2013 at 09:33:04 UTC, Bienlein wrote:
What puzzles me is the enormous activity in the Go forum. Only
the Python forum has that much traffic. It seems to me that
people are all that happy if they have a language with which
they
can just start hacking around on something.
There are a lot of SMEs in London using Go as their core
language. Their
enthusiasm stems, I think, from otherwise having to use C.
Well, I think that says it all. Go is made by C programmers for C
programmers. I would say that this is even objectively correct.
What puzzles me is the enormous
I think, @property should be removed. Requiring to mark
properties with an annotation to make them work unambiguously is
bug-prone, because you can forget to do so and nothing will warn
you.
On Thursday, 21 November 2013 at 08:05:03 UTC, Michal Minich
wrote:
On Thursday, 21 November 2013 at 07:42:48 UTC, Craig Dillabaugh
wrote:
I should also mention, this post likely better belongs in:
digitalmars.D.learn
I don't entirely think so. I think the OP is arguing that D
should be able
On 2013-11-21 09:01, luka8088 wrote:
When using q{} compiler treats the contents as a regular string, and you
have to parse it and give it to the compiler using "mixin". So basically
you can say to the compiler: this part of code is my DSL and I will
parse it and check the semantics instead of y
On 2013-11-21 08:46, Jonathan M Davis wrote:
You could use alias this and alias the Validated struct to the underlying
string, but if you did that, you'd probably end up having it escape the struct
and used as a naked string the vast majority of the time, which would
essentially defeat the purpo
On Thursday, 21 November 2013 at 07:42:48 UTC, Craig Dillabaugh
wrote:
I should also mention, this post likely better belongs in:
digitalmars.D.learn
I don't entirely think so. I think the OP is arguing that D
should be able to identify symbol as specific enum's field when
used:
- in place
On 21.11.2013. 8:28, Jacob Carlborg wrote:
> On 2013-11-20 23:25, luka8088 wrote:
>
>> If I understood you correctly, the issue with current way DSLs are
>> implemented is that code needs to be parsed two times. First time DSL
>> author parses it and creates D code from it, and second time D compi
On Thursday, 21 November 2013 at 07:22:39 UTC, Steve Teale wrote:
import std.stdio;
enum Intention
{
EVIL,
NEUTRAL,
GOOD,
SAINTLY
}
void foo(Intention rth)
{
if (rth == EVIL)
writeln("Road to hell");
}
void main()
{
foo(EVIL);
}
Why does the compiler complain in both
On Thursday, 21 November 2013 at 07:36:38 UTC, Jacob Carlborg
wrote:
On 2013-11-20 19:53, Meta wrote:
Yes. It is very important not to allow direct access to the
underlying
value. This is important for ensuring that it is not put in an
invalid
state. This is a mistake that was made with
std.t
97 matches
Mail list logo
