On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu
wrote:
There's some experience in various libraries with both
approaches. Which would you prefer?
Another thing: wouldn't providing a custom allocator require a
separate primitive? I am assuming that the allocator type won't
be
On Saturday, 28 November 2015 at 06:59:35 UTC, bitwise wrote:
Classes/real-ref-types dont act as you're describing
They do, actually.
class Collection(E) { ... }
Collection!E a; // null reference
auto b = new Collection!E(); // reference to empty collection
The only outlier is the associativ
On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu
wrote:
There's some experience in various libraries with both
approaches. Which would you prefer?
Well, I think we should recognize that they're the same thing but
with different names. I don't have a strong preference for
eithe
On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu
wrote:
There's this oddity of built-in hash tables: a reference to a
non-empty hash table can be copied and then both references
refer to the same hash table object. However, if the hash table
is null, copying the reference won't
On Friday, 27 November 2015 at 20:25:12 UTC, Adam D. Ruppe wrote:
That syntax is the same as constructors... if that's what you
want it to look like, we ought to actually use a constructor
for all but the zero-argument ones which I'd use a static named
function for (perhaps .make or perhaps .ma
On Wed, 25 Nov 2015 12:48:51 +, Kagamin wrote:
> On Wednesday, 25 November 2015 at 12:43:01 UTC, Chris wrote:
>> What about JSON with comments? You could always strip them. But I admit
>> that JSON becomes a bit messy after a while. It's not ideal. As I said,
>> nothing against SDL as long as
On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu
wrote:
There's this oddity of built-in hash tables: a reference to a
non-empty hash table can be copied and then both references
refer to the same hash table object. However, if the hash table
is null, copying the reference won't
On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote:
If SDL will stay by default I will prefer to move to any other
build system or will downgrade to old version of DUB.
JSON +1
On Saturday, 28 November 2015 at 02:01:36 UTC, Vladimir Panteleev
wrote:
On Friday, 27 November 2015 at 16:23:46 UTC, Gordon wrote:
[snip]
Please no personal attacks on these forums. Keep it civil.
Why not tell that to Dicebot? He spends half his time being a
drama queen and spends the othe
On Thursday, 26 November 2015 at 08:47:41 UTC, Sönke Ludwig wrote:
Mar. 09, 2013: First call for comments for a new package format
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/
May 24, 2013: Concrete DUB enhancement proposal (DEP)
https://github.com/D-Programming-Langua
On Friday, 27 November 2015 at 16:23:46 UTC, Gordon wrote:
[snip]
Please no personal attacks on these forums. Keep it civil.
On Friday, 27 November 2015 at 23:26:27 UTC, karabuta wrote:
This question came into mind when I read this
http://www.makeuseof.com/answers/which-programming-language-is-used-to-build-a-financial-trading-platform/
Quant is a big domain these days, and I don't think there is one
answer to that
This question came into mind when I read this
http://www.makeuseof.com/answers/which-programming-language-is-used-to-build-a-financial-trading-platform/
On Friday, 27 November 2015 at 22:18:28 UTC, Walter Bright wrote:
"With a standard json parser in Phobos, zip zap boom you're
done. You don't have to design it, argue about it, build it,
document it, debug it, test it, optimize it, explain it, deal
with bug requests, deal with enhancement req
On Friday, 27 November 2015 at 08:09:27 UTC, tcak wrote:
On Friday, 27 November 2015 at 05:33:52 UTC, deadalnix wrote:
I see many solution here that do not require any language
change. To start, have a linter yell at the programmer when
(s)he submit a diff. Dev commit directly ? What the fuck a
On Friday, 27 November 2015 at 18:37:13 UTC, Alexander wrote:
import std.stdio;
import derelict.opengl3.gl3;
import derelict.glfw3.glfw3;
pragma(lib,
"C:\\Users\\Alexander\\AppData\\Roaming\\dub\\packages\\derelict-gl3-1.0.17\\lib\\DerelictGL3");
pragma(lib,
"C:\\Users\\Alexander\\AppData\\Roa
I've read latest months several related topics (multiple alias
this, super struct, etc). But the problem is that these solutions
still differ from a real interface and they don't solve the
problem of casting the interface at run-time (with arbitrary
parameters).
I'll expose another approach.
On Friday, 27 November 2015 at 19:42:43 UTC, Chris wrote:
At the end of the day, all markup, data exchange or description
languages are not easy on the eye. It's a question of "which is
worse", and that's often a question of personal taste.
Yes, syntax is rather personal! Some GNU people want
On 11/27/2015 2:10 PM, terchestor wrote:
On Friday, 27 November 2015 at 21:00:38 UTC, bubbasaur wrote:
On Friday, 27 November 2015 at 20:47:04 UTC, Walter Bright wrote:
On 11/27/2015 11:41 AM, Mathias Lang wrote:
What is the problem in having multiple formats
I posted a list twice upthread.
On Friday, 27 November 2015 at 21:00:38 UTC, bubbasaur wrote:
On Friday, 27 November 2015 at 20:47:04 UTC, Walter Bright
wrote:
On 11/27/2015 11:41 AM, Mathias Lang wrote:
What is the problem in having multiple formats
I posted a list twice upthread.
Do you mind to link? This is a huge thre
On Friday, 27 November 2015 at 20:16:20 UTC, Minas Mina wrote:
SDLang is fine. If someone wants to use D, it won't be SDLang
that will stop him.
Keep calm and use SDLang.
No. STDLang is a terrible idea. Walter's arguments are right on.
Drop the drama and stop complaining you are not microman
On Friday, 27 November 2015 at 20:19:40 UTC, tcak wrote:
if(1) doSomething();
if(1) { doSomething(); }
You are correct here about hash calculation, but unless someone
touches to codes, this never happens, and no hash changes would
be seen. If someone is touching it as you exampled, checking
t
On Friday, 27 November 2015 at 21:00:38 UTC, bubbasaur wrote:
On Friday, 27 November 2015 at 20:47:04 UTC, Walter Bright
wrote:
On 11/27/2015 11:41 AM, Mathias Lang wrote:
What is the problem in having multiple formats
I posted a list twice upthread.
Do you mind to link? This is a huge thre
On Friday, 27 November 2015 at 20:47:04 UTC, Walter Bright wrote:
On 11/27/2015 11:41 AM, Mathias Lang wrote:
What is the problem in having multiple formats
I posted a list twice upthread.
Do you mind to link? This is a huge thread now!
On 11/27/2015 11:41 AM, Mathias Lang wrote:
What is the problem in having multiple formats
I posted a list twice upthread.
On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu
wrote:
1. Factory function:
This is my preference for zero arg at least because the opCall
thing is commonly misunderstood and confused with C++ default
construction and we don't need to encourage that.
static MyCollectio
On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu
wrote:
There's this oddity of built-in hash tables: a reference to a
non-empty hash table can be copied and then both references
refer to the same hash table object. However, if the hash table
is null, copying the reference won't
On Friday, 27 November 2015 at 20:00:16 UTC, bitwise wrote:
On Friday, 27 November 2015 at 18:51:54 UTC, tcak wrote:
On Friday, 27 November 2015 at 16:18:52 UTC, bitwise wrote:
On Friday, 27 November 2015 at 08:09:27 UTC, tcak wrote:
Yours are not helping, making everything more complex.
Yes
SDLang is fine. If someone wants to use D, it won't be SDLang
that will stop him.
Keep calm and use SDLang.
There's this oddity of built-in hash tables: a reference to a non-empty
hash table can be copied and then both references refer to the same hash
table object. However, if the hash table is null, copying the reference
won't track the same object later on.
Fast-forward to general collections. If
On Friday, 27 November 2015 at 18:51:54 UTC, tcak wrote:
On Friday, 27 November 2015 at 16:18:52 UTC, bitwise wrote:
On Friday, 27 November 2015 at 08:09:27 UTC, tcak wrote:
Yours are not helping, making everything more complex.
Yes, because to achieve what you're asking for, you NEED a
comp
On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote:
I think that using SDL format was big mistake. Not only I do
not want to spend time in learning yet another dead config
format that now use only one project -- DUB. In time when DUB
used json it was not perfect, but at last it was s
On Friday, 27 November 2015 at 18:58:12 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 27 November 2015 at 18:27:57 UTC, Chris wrote:
But JSON is widely used and chances are that people are
already familiar with it. If not, it's easy to learn, there
are loads of resources. 3rd party tools can easil
On 2015-11-27 08:55, Sönke Ludwig wrote:
That would mean more work for everyone and consequently less adoption.
How so? It's the same amount of commands, maybe one extra.
Seriously, I think it's the best approach possible and really couldn't
imagine using a more manual system to the extend t
On 2015-11-25 11:17, Suliman wrote:
I think that using SDL format was big mistake. Not only I do not want to
spend time in learning yet another dead config format that now use only
one project -- DUB. In time when DUB used json it was not perfect, but
at last it was standard and everybody can rea
On Friday, 27 November 2015 at 18:27:57 UTC, Chris wrote:
But JSON is widely used and chances are that people are already
familiar with it. If not, it's easy to learn, there are loads
of resources. 3rd party tools can easily parse it. And hey,
it's not that bad.
Well, many are familiar with J
On Friday, 27 November 2015 at 16:18:52 UTC, bitwise wrote:
On Friday, 27 November 2015 at 08:09:27 UTC, tcak wrote:
Yours are not helping, making everything more complex.
Yes, because to achieve what you're asking for, you NEED a
complex solution.
The code WILL change with every release..t
On Friday, 27 November 2015 at 18:31:19 UTC, rsw0x wrote:
On Friday, 27 November 2015 at 18:27:57 UTC, Chris wrote:
On Friday, 27 November 2015 at 18:11:34 UTC, Ola Fosheim
Grøstad wrote:
[...]
But JSON is widely used and chances are that people are
already familiar with it. If not, it's eas
import std.stdio;
import derelict.opengl3.gl3;
import derelict.glfw3.glfw3;
pragma(lib,
"C:\\Users\\Alexander\\AppData\\Roaming\\dub\\packages\\derelict-gl3-1.0.17\\lib\\DerelictGL3");
pragma(lib,
"C:\\Users\\Alexander\\AppData\\Roaming\\dub\\packages\\derelict-glfw3-master\\lib\\DerelictGLFW3"
On Friday, 27 November 2015 at 18:27:57 UTC, Chris wrote:
On Friday, 27 November 2015 at 18:11:34 UTC, Ola Fosheim
Grøstad wrote:
On Friday, 27 November 2015 at 17:51:40 UTC, Chris wrote:
DUB works out of the box. dub init myproject.
Wasn't smack-talking DUB. Just pointing out that any type o
On Friday, 27 November 2015 at 18:11:34 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 27 November 2015 at 17:51:40 UTC, Chris wrote:
DUB works out of the box. dub init myproject.
Wasn't smack-talking DUB. Just pointing out that any type of
modification of a config file is a turnoff for a newbie,
On Friday, 27 November 2015 at 17:51:40 UTC, Chris wrote:
DUB works out of the box. dub init myproject.
Wasn't smack-talking DUB. Just pointing out that any type of
modification of a config file is a turnoff for a newbie, no
matter what format it is in.
(and for me and many others JSON woul
On Friday, 27 November 2015 at 17:05:18 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 27 November 2015 at 16:53:35 UTC, Chris wrote:
especially in the case of D. "Weird config format" would be
one of those reasons / excuses not to use D. I bet you! It
would certainly get mentioned in some tech art
On Friday, 27 November 2015 at 16:53:35 UTC, Chris wrote:
especially in the case of D. "Weird config format" would be one
of those reasons / excuses not to use D. I bet you! It would
certainly get mentioned in some tech article about D.
JSON falls into the same category.
Newbies want things t
On Friday, 27 November 2015 at 16:48:26 UTC, Ola Fosheim Grøstad
wrote:
Yes, it isn't irrelevant and end users should of course express
where it cause them head aches it it does.
However, it does not affect adoption. I don't think high
quality libraries will be held back from publication ove
On Friday, 27 November 2015 at 16:32:57 UTC, Chris wrote:
DUB does matter, because it's the official package manager and
is used by developers and will likely be used by newcomers too.
It should offer as good a user experience as possible.
Yes, it isn't irrelevant and end users should of cours
On 2015-11-27 10:24, Ola Fosheim Grøstad wrote:
Well, I usually don't use package managers for source code, but if I did
I would not consider using one that can write to random directories.
So if one uses Ruby, Python or D, the package manager has to make sure
it executes in a "jail filesystem
On Friday, 27 November 2015 at 16:27:07 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 27 November 2015 at 15:58:40 UTC, Chris wrote:
Basically yes. But if it concerns "offical D" things should be
synchronized better.
Maybe defining what the inclusion process for "official D" is
and set down po
On Friday, 27 November 2015 at 15:58:40 UTC, Chris wrote:
Basically yes. But if it concerns "offical D" things should be
synchronized better.
Maybe defining what the inclusion process for "official D" is and
set down policies for decision making processes and quality
assurance for those pro
On Thursday, 26 November 2015 at 20:56:04 UTC, Bruno Medeiros
wrote:
On 26/11/2015 12:53, Daniel Kozak via Digitalmars-d wrote:
V Thu, 26 Nov 2015 12:43:52 +
Chris via Digitalmars-d napsáno:
On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg
wrote:
On 2015-11-25 11:17, Suliman
On Friday, 27 November 2015 at 08:09:27 UTC, tcak wrote:
Yours are not helping, making everything more complex.
Yes, because to achieve what you're asking for, you NEED a
complex solution.
The code WILL change with every release..thats the point of a
release.. so any hashing mechanism like
On Friday, 27 November 2015 at 15:49:48 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 27 November 2015 at 15:35:32 UTC, Chris wrote:
That's why I said that (timely) communication is of utmost
importance. Post factum decisions are bound to cause trouble.
Yes, I agree. So then one should just stand
On Friday, 27 November 2015 at 15:35:32 UTC, Chris wrote:
That's why I said that (timely) communication is of utmost
importance. Post factum decisions are bound to cause trouble.
Yes, I agree. So then one should just stand by whatever the
maintainer has chosen, because he is more likely to hav
On Friday, 27 November 2015 at 15:29:38 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 27 November 2015 at 15:18:38 UTC, Chris wrote:
Yes. But a (well-informed) decision has to be made at some
point. And it's the leaders who have to make them. I often
find myself agreeing with both sides, I'd be te
Today old languages evolve - Java, C#, C, C++, Python - while D
stabilizes. I wonder if it's right strategy or D just needs a
period of stabilization to resolve implementation bugs.
On Friday, 27 November 2015 at 15:18:38 UTC, Chris wrote:
Yes. But a (well-informed) decision has to be made at some
point. And it's the leaders who have to make them. I often find
myself agreeing with both sides, I'd be terrible at making
decisions.
It is terribly expensive to postpone the d
On 11/26/2015 2:27 PM, CraigDillabaugh wrote:
Ok, but we can afford to mantain a parser for a dead format?
https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Simple_Declarative_Language
BAM!! *Daniel drops mike, walks way*
(well said)
Isn't it easier to maintain a parser for a dead f
On 11/26/2015 11:08 PM, Sönke Ludwig wrote:
This looks like it's creeping towards inventing a new script programming
language. Adding loops, switch statements, functions, etc., can't be far
off. Before you get too far down this path, consider:
Actually, no! Conditionals and loops are the only c
On Friday, 27 November 2015 at 15:04:15 UTC, Kagamin wrote:
On Friday, 27 November 2015 at 14:57:36 UTC, Chris wrote:
There are two things at loggerheads here: a) the call for
strong leadership and b) the desire to make decisions based on
open discussions within the community.
It's certainly
On Friday, 27 November 2015 at 14:57:36 UTC, Chris wrote:
If anything, this thread shows that there has to be more
communication between the developers. It's detrimental, when
discontent builds up behind the scenes only to erupt suddenly
over a minor issue.
There are two things at loggerhe
On Friday, 27 November 2015 at 14:57:36 UTC, Chris wrote:
There are two things at loggerheads here: a) the call for
strong leadership and b) the desire to make decisions based on
open discussions within the community.
It's certainly not easy to find the right balance, which is why
better comm
On Friday, 27 November 2015 at 14:04:26 UTC, B.Basile wrote:
On Friday, 27 November 2015 at 13:52:58 UTC, wobbles wrote:
On Friday, 27 November 2015 at 13:52:13 UTC, wobbles wrote:
On Friday, 27 November 2015 at 11:04:09 UTC, Chris wrote:
Our house doesn't stand properly yet and we're discussin
On Friday, 27 November 2015 at 07:31:35 UTC, Jack Applegame wrote:
Sublime Text configuration has a lot of comments:
// Place your settings in the file
"User/Preferences.sublime-settings", which
// overrides the settings in here.
//
// Settings may also be placed in file type specific options
On Friday, 27 November 2015 at 13:52:58 UTC, wobbles wrote:
On Friday, 27 November 2015 at 13:52:13 UTC, wobbles wrote:
On Friday, 27 November 2015 at 11:04:09 UTC, Chris wrote:
Our house doesn't stand properly yet and we're discussing
effin bikesheds.
+10
Everyones opinion is different, no
On Friday, 27 November 2015 at 11:04:09 UTC, Chris wrote:
Our house doesn't stand properly yet and we're discussing effin
bikesheds.
+10
Everyones opinion is different, no one is right, no one is wrong
- It's all just opinion.
The only thing it's served to do is piss off a very important
c
On Friday, 27 November 2015 at 13:52:13 UTC, wobbles wrote:
On Friday, 27 November 2015 at 11:04:09 UTC, Chris wrote:
Our house doesn't stand properly yet and we're discussing
effin bikesheds.
+10
Everyones opinion is different, no one is right, no one is
wrong - It's all just opinion.
The
On Friday, 27 November 2015 at 13:46:37 UTC, Joseph Rushton
Wakeling wrote:
I think the distinction here is artificial. If `range` is a
random number generator
... should read, "If `range` is a random number generator (even a
pseudo-random one)".
On Friday, 27 November 2015 at 12:16:34 UTC, Jonathan M Davis
wrote:
Well, if you're dealing with a pseudo-random generator with a
specific seed, I'm not sure that it's okay, though obviously
for a fully random number generator, it wouldn't matter.
I think the distinction here is artificial.
On Friday, 27 November 2015 at 12:29:19 UTC, Marc Schütz wrote:
On Friday, 27 November 2015 at 12:20:03 UTC, Chris wrote:
Taking a break from bikeshedding:
DConf 2015 is still being advertised here:
http://wiki.dlang.org/
I think we need to update this.
Done, thanks.
Thank you.
Am 26.11.2015 um 21:41 schrieb Bruno Medeiros:
On 26/11/2015 16:10, Sönke Ludwig wrote:
The only valid reason for an IDE to directly parse the package
description is basically if it wants to provide a custom UI for editing
it. If the IDE is written in D, it can easily use DUB as a library and
n
On Friday, 27 November 2015 at 12:20:03 UTC, Chris wrote:
Taking a break from bikeshedding:
DConf 2015 is still being advertised here:
http://wiki.dlang.org/
I think we need to update this.
Done, thanks.
On Friday, 27 November 2015 at 12:19:14 UTC, Gary Willoughby
wrote:
On Thursday, 26 November 2015 at 22:46:57 UTC, Walter Bright
wrote:
"With a standard json parser in Phobos, zip zap boom you're
done. You don't have to design it, argue about it, build it,
document it, debug it, test it, optimi
Taking a break from bikeshedding:
DConf 2015 is still being advertised here:
http://wiki.dlang.org/
I think we need to update this.
On Thursday, 26 November 2015 at 22:46:57 UTC, Walter Bright
wrote:
"With a standard json parser in Phobos, zip zap boom you're
done. You don't have to design it, argue about it, build it,
document it, debug it, test it, optimize it, explain it, deal
with bug requests, deal with enhancement req
On Friday, 27 November 2015 at 12:06:02 UTC, Joseph Rushton
Wakeling wrote:
On Friday, 27 November 2015 at 11:57:37 UTC, Jonathan M Davis
wrote:
Well, you can have a pure input range which is lazy, but what
you can't do is wrap it in another lazy range. A prime example
would be something like
On Friday, 27 November 2015 at 11:57:37 UTC, Jonathan M Davis
wrote:
Well, you can have a pure input range which is lazy, but what
you can't do is wrap it in another lazy range. A prime example
would be something like
auto first5 = range.take(5);
range.popFront();
range.popFront();
On Thursday, 26 November 2015 at 22:46:57 UTC, Walter Bright
wrote:
1. JSON has a superset programming language - Javascript -
which has conventional syntax rather than the DEP4 proposal for
odd syntax like
if dub-version="<0.9.24"
which I would strongly recommend against. And, we alr
On Friday, 27 November 2015 at 11:45:38 UTC, Joseph Rushton
Wakeling wrote:
On Friday, 27 November 2015 at 11:31:14 UTC, Jonathan M Davis
wrote:
Another piece of this puzzle to consider is that unless a
range is a value type (or at least acts like a value type as
long as you don't mutate its el
On Friday, 27 November 2015 at 11:31:14 UTC, Jonathan M Davis
wrote:
Another piece of this puzzle to consider is that unless a range
is a value type (or at least acts like a value type as long as
you don't mutate its elements) or has save called on it, then
it fundamentally doesn't work with la
On Friday, 27 November 2015 at 09:20:23 UTC, Jonathan M Davis
wrote:
I'm starting to think that it would be better to have pure
input ranges have to be reference types and forward ranges have
to be value types and then be very careful about which
functions work with both rather than simply trea
On Friday, 27 November 2015 at 00:39:12 UTC, Daniel Kozák wrote:
V Thu, 26 Nov 2015 22:27:06 +
CraigDillabaugh via Digitalmars-d
napsáno:
On Thursday, 26 November 2015 at 20:56:04 UTC, Bruno Medeiros
wrote:
> On 26/11/2015 12:53, Daniel Kozak via Digitalmars-d wrote:
>> V Thu, 26 Nov 20
On Wed, 2015-11-25 at 19:06 -0500, Andrei Alexandrescu via Digitalmars-
d wrote:
[…]
Re JSON vs SDL, switch to TOML, Rust did and it solved the Cargo
configuration situation "at a stroke".
--
Russel.
=
Dr Russel Winder
On Thursday, 26 November 2015 at 22:27:08 UTC, CraigDillabaugh
wrote:
On Thursday, 26 November 2015 at 20:56:04 UTC, Bruno Medeiros
wrote:
On 26/11/2015 12:53, Daniel Kozak via Digitalmars-d wrote:
V Thu, 26 Nov 2015 12:43:52 +
Chris via Digitalmars-d napsáno:
On Thursday, 26 November 20
On Friday, 27 November 2015 at 10:17:46 UTC, Joseph Rushton
Wakeling wrote:
On Friday, 27 November 2015 at 09:20:23 UTC, Jonathan M Davis
wrote:
Obviously, Andrei will have to answer to know what he meant,
but with regards to ranges, I would consider a reference type
to be one where in
auto c
On Thursday, 26 November 2015 at 19:05:46 UTC, Sönke Ludwig wrote:
Just to mention one additional reason for choosing SDLang over
one of the more popular formats that shared some of the
advantages, there is an idea to add limited support for
(declarative) procedural statements:
https://github.
On Friday, 27 November 2015 at 09:20:23 UTC, Jonathan M Davis
wrote:
Obviously, Andrei will have to answer to know what he meant,
but with regards to ranges, I would consider a reference type
to be one where in
auto copy = range;
doing anything to copy or range does the exact same thing to
t
The bug report is https://issues.dlang.org/show_bug.cgi?id=15324
On Friday, 27 November 2015 at 07:08:40 UTC, Sönke Ludwig wrote:
Actually, no! Conditionals and loops are the only constructs -
switch is a possibility, but basically nothing else. There will
also never be variables, just constants. There is a definitive
limit, namely when it becomes impossible
On Friday, 27 November 2015 at 08:53:26 UTC, Joseph Rushton
Wakeling wrote:
On Thursday, 26 November 2015 at 17:23:07 UTC, Andrei
Alexandrescu wrote:
So initially I thought a simple solution would be this:
struct MyForwardRange
{
enum bool isForward = true;
... empty, front, popFront ..
On Friday, 27 November 2015 at 07:15:51 UTC, Jacob Carlborg wrote:
This is (one of the reasons) why people complain. The problem
with D is that it won't be pretty.
Well, I usually don't use package managers for source code, but
if I did I would not consider using one that can write to random
On Thursday, 26 November 2015 at 20:54:27 UTC, Bruno Medeiros
wrote:
But if we really wanted a more succinct format, why not go with
TOML instead of SDL?
AFAIK the author of SDL is a java programmer and Oracle licensed
SDL for internal use.
On Friday, 27 November 2015 at 07:08:40 UTC, Sönke Ludwig wrote:
Actually, no! Conditionals and loops are the only constructs -
switch is a possibility, but basically nothing else. There will
also never be variables, just constants. There is a definitive
limit, namely when it becomes impossible
On Thursday, 26 November 2015 at 17:23:07 UTC, Andrei
Alexandrescu wrote:
So initially I thought a simple solution would be this:
struct MyForwardRange
{
enum bool isForward = true;
... empty, front, popFront ...
}
enum isForwardRange(R) =
is(typeof(R.isForward)) && R.isForward;
Then
On Thursday, 26 November 2015 at 11:12:07 UTC, tcak wrote:
What is needed is to be able to bind a hash value to any block
with a name.
I've thought about this too in the past and asked on the forums
but I haven't gotten any response.
It is possible. The problem is easier in dynamic languages
On Friday, 27 November 2015 at 05:33:52 UTC, deadalnix wrote:
I see many solution here that do not require any language
change. To start, have a linter yell at the programmer when
(s)he submit a diff. Dev commit directly ? What the fuck are
you doing ? Do code review and get a linter.
Alterna
Am 27.11.2015 um 08:29 schrieb Jacob Carlborg:
Personally I think Dub and code.dlang.org is designed completely wrong.
Currently Dub works by the user pushing new code to the repository on
GitHub and code.dlang.org watching for changes. If the user instead
would use Dub to build a package locally
96 matches
Mail list logo
