On Wednesday, 25 October 2017 at 18:54:16 UTC, bauss wrote:
On Wednesday, 25 October 2017 at 16:07:21 UTC, ecstatic.coder
wrote:
[...]
Syntactic sugar is what makes a language easy to learn, because
you don't have to memorize functions, their modules and whether
you imported them or not,
On Wednesday, 25 October 2017 at 16:07:21 UTC, ecstatic.coder
wrote:
On Tuesday, 24 October 2017 at 08:06:55 UTC, Atila Neves wrote:
[...]
I agree. D MUST remain as simple as possible.
For instance I'm against forcing D programmers to use
annotations which won't be implicit anymore.
Keep
On Tuesday, 24 October 2017 at 08:06:55 UTC, Atila Neves wrote:
On Tuesday, 24 October 2017 at 07:17:08 UTC, Satoshi wrote:
On Monday, 23 October 2017 at 21:42:03 UTC, Atila Neves wrote:
On Monday, 23 October 2017 at 21:14:18 UTC, bauss wrote:
On Monday, 23 October 2017 at 12:48:33 UTC, Atila
On Friday, 20 October 2017 at 00:26:19 UTC, bauss wrote:
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
conditional dereferencing and stuff about that (same as in C#)
...
...
implement this thing from C# (just because it's cool)
new Foo() {
property1 = 42,
property2 = "bar"
On Tuesday, 24 October 2017 at 18:55:13 UTC, Martin Nowak wrote:
On Monday, 23 October 2017 at 11:58:14 UTC, Laeeth Isharc wrote:
Bountysource went quiet, though I started contributing to it.
I wonder if there is a better way for commercial users to say
what they might be willing to pay for
On 10/25/2017 12:39 AM, Satoshi wrote:
Thanks, but I see there 3 problems:
1. this example enforce users to use composition instead of inheritance when
they wants to create custom descendant.
I don't see an issue with that.
2. multiple dispatch levels. Extending the ExtendView in another lib
On Tuesday, 24 October 2017 at 20:36:47 UTC, Walter Bright wrote:
On 10/24/2017 3:36 AM, Satoshi wrote:
Can you provide an example?
I'd start with https://dlang.org/spec/interface.html
You'll see the same thing with Windows COM programming, and
using interfaces in Java.
view.di
On 23.10.2017 22:47, Walter Bright wrote:
On 10/18/2017 1:56 AM, Satoshi wrote:
Unable to publish closed source library without workaround and ugly
PIMPL design.
Consider this:
--- file s.d
struct S {
int x;
this(int x) { this.x = x; }
int getX() {
On 10/24/2017 3:36 AM, Satoshi wrote:
Can you provide an example?
I'd start with https://dlang.org/spec/interface.html
You'll see the same thing with Windows COM programming, and using interfaces in
Java.
view.di
interface View {
void render();
}
View createView();
On Monday, October 23, 2017 13:18:21 Guillaume Piolat via Digitalmars-d
wrote:
> On Monday, 23 October 2017 at 11:39:58 UTC, Martin Nowak wrote:
> >> Every-symbol-public-by-default in Posix is annoying though :)
> >
> > We agreed on hidden visibility by default for everything that's
> > not
On Tuesday, October 24, 2017 18:53:49 Martin Nowak via Digitalmars-d wrote:
> On Monday, 23 October 2017 at 13:18:21 UTC, Guillaume Piolat
>
> wrote:
> >> By any means, if someone wants to help here, get in touch with
> >> Benjamin Thaut and me.
> >> This has been lingering around for way to long,
On Monday, 23 October 2017 at 11:58:14 UTC, Laeeth Isharc wrote:
Bountysource went quiet, though I started contributing to it.
I wonder if there is a better way for commercial users to say
what they might be willing to pay for and how much.
At best talk to Andrei, maybe you have a good idea
On Monday, 23 October 2017 at 13:18:21 UTC, Guillaume Piolat
wrote:
By any means, if someone wants to help here, get in touch with
Benjamin Thaut and me.
This has been lingering around for way to long, and Benjamin
alone has a hard time pushing this.
Would Bountysource help be adequate?
Not
On Tuesday, 24 October 2017 at 09:56:50 UTC, rikki cattermole
wrote:
scope+ref+out as arguments would be a no-no.
Now if we could ditch registers usage crossing before/after
yield, we wouldn't need to do 'patching' like fibers do.
That's basically what asnyc/await does, some implementations
On Tuesday, 24 October 2017 at 16:02:56 UTC, flamencofantasy
wrote:
On Tuesday, 24 October 2017 at 05:40:06 UTC, Dmitry Olshansky
wrote:
On Tuesday, 24 October 2017 at 04:26:42 UTC, Adam Wilson wrote:
[...]
I’ll throw in my 2 rubbles.
I actually worked on a VM that has async/await feature
On Tuesday, 24 October 2017 at 05:40:06 UTC, Dmitry Olshansky
wrote:
On Tuesday, 24 October 2017 at 04:26:42 UTC, Adam Wilson wrote:
[...]
I’ll throw in my 2 rubbles.
I actually worked on a VM that has async/await feature built-in
(Dart language).
It is a plain syntax sugar for
On Tuesday, 24 October 2017 at 04:26:42 UTC, Adam Wilson wrote:
(at the end of the day all of these programming models are
callback based).
That's what APM is, no?
Yes, C#'s async design does make code look and feel
synchronous, and it was intentionally designed that way, but
that is not
On Monday, 23 October 2017 at 21:42:03 UTC, Atila Neves wrote:
On Monday, 23 October 2017 at 21:14:18 UTC, bauss wrote:
On Monday, 23 October 2017 at 12:48:33 UTC, Atila Neves wrote:
On Monday, 23 October 2017 at 09:13:45 UTC, Satoshi wrote:
On Wednesday, 18 October 2017 at 08:56:21 UTC,
On Tuesday, 24 October 2017 at 10:20:43 UTC, Walter Bright wrote:
On 10/24/2017 1:13 AM, Satoshi wrote:
But it's quite useless to me.
That's what interfaces are for. Define your View and Button as
interfaces. The implementations of interfaces are completely
hidden from the derived class.
On 10/24/2017 1:13 AM, Satoshi wrote:
But it's quite useless to me.
That's what interfaces are for. Define your View and Button as interfaces. The
implementations of interfaces are completely hidden from the derived class.
But the worst part is that I need to hold di in sync to d files
On 24/10/2017 10:31 AM, Kagamin wrote:
On Tuesday, 24 October 2017 at 07:29:08 UTC, Satoshi wrote:
If we want to use D for GUI development we will need this feature anyway.
To not block UI you need non-blocking IO, and async/await is not
required for it: vibe provides non-blocking IO with
On Tuesday, 24 October 2017 at 07:29:08 UTC, Satoshi wrote:
If we want to use D for GUI development we will need this
feature anyway.
To not block UI you need non-blocking IO, and async/await is not
required for it: vibe provides non-blocking IO with synchronous
interface. And here we also
On Monday, 23 October 2017 at 22:22:55 UTC, Adam Wilson wrote:
Async/Await trades raw performance for an ability to handle a
truly massive number of simultaneous tasks.
Vibe achieves the same without trading performance. Then
async/await only amounts to easy creation of tasks not even for
On Tuesday, 24 October 2017 at 08:06:55 UTC, Atila Neves wrote:
On Tuesday, 24 October 2017 at 07:17:08 UTC, Satoshi wrote:
On Monday, 23 October 2017 at 21:42:03 UTC, Atila Neves wrote:
On Monday, 23 October 2017 at 21:14:18 UTC, bauss wrote:
On Monday, 23 October 2017 at 12:48:33 UTC, Atila
On Tuesday, 24 October 2017 at 07:55:49 UTC, Walter Bright wrote:
On 10/24/2017 12:21 AM, Satoshi wrote:
what about this:
-- file.d
class Foo {
private int bar;
private string text;
void call() { }
}
--- file.di
class Foo {
call();
}
and then I want to inherit
On Tuesday, 24 October 2017 at 07:17:08 UTC, Satoshi wrote:
On Monday, 23 October 2017 at 21:42:03 UTC, Atila Neves wrote:
On Monday, 23 October 2017 at 21:14:18 UTC, bauss wrote:
On Monday, 23 October 2017 at 12:48:33 UTC, Atila Neves wrote:
On Monday, 23 October 2017 at 09:13:45 UTC,
On 10/24/2017 12:21 AM, Satoshi wrote:
what about this:
-- file.d
class Foo {
private int bar;
private string text;
void call() { }
}
--- file.di
class Foo {
call();
}
and then I want to inherit from it (I have access to file.di only)
class Bar : Foo { // I
On Monday, 23 October 2017 at 12:48:33 UTC, Atila Neves wrote:
On Monday, 23 October 2017 at 09:13:45 UTC, Satoshi wrote:
writeln(`Foo is {foo} and bar is {bar}`);
writeln("Foo is ", foo, "and bar is ", bar");
Two more characters.
You have actually demonstrates exactly what I feel is the
On Monday, 23 October 2017 at 15:21:02 UTC, Kagamin wrote:
On Friday, 20 October 2017 at 09:49:34 UTC, Adam Wilson wrote:
Others are less obvious, for example, async/await is syntax
sugar for a collection of Task-based idioms in C#.
Now I think it's doesn't fit D. async/await wasn't made for
On Monday, 23 October 2017 at 20:47:26 UTC, Walter Bright wrote:
On 10/18/2017 1:56 AM, Satoshi wrote:
Unable to publish closed source library without workaround and
ugly PIMPL design.
Consider this:
--- file s.d
struct S {
int x;
this(int x) { this.x = x; }
On Monday, 23 October 2017 at 21:42:03 UTC, Atila Neves wrote:
On Monday, 23 October 2017 at 21:14:18 UTC, bauss wrote:
On Monday, 23 October 2017 at 12:48:33 UTC, Atila Neves wrote:
On Monday, 23 October 2017 at 09:13:45 UTC, Satoshi wrote:
On Wednesday, 18 October 2017 at 08:56:21 UTC,
23.10.2017 23:25, Igor пишет:
On Monday, 23 October 2017 at 11:02:41 UTC, Martin Nowak wrote:
In C++ incremental rebuilds are simple as you compile each file
individually anyhow, but that's the crux for why C++ compilations are
so slow in the first place.
Compiling multiple modules at once
On 10/23/17 22:40, Dmitry Olshansky wrote:
On Tuesday, 24 October 2017 at 04:26:42 UTC, Adam Wilson wrote:
On 10/23/17 17:27, flamencofantasy wrote:
On Monday, 23 October 2017 at 22:22:55 UTC, Adam Wilson wrote:
On 10/23/17 08:21, Kagamin wrote:
[...]
Actually I think it fits perfectly
On 10/23/17 16:47, Nathan S. wrote:
On Monday, 23 October 2017 at 22:22:55 UTC, Adam Wilson wrote:
Additionally, MSFT/C# fully recognizes that the benefits of
Async/Await have never been and never were intended to be for
performance. Async/Await trades raw performance for an ability to
handle a
On Tuesday, 24 October 2017 at 04:26:42 UTC, Adam Wilson wrote:
On 10/23/17 17:27, flamencofantasy wrote:
On Monday, 23 October 2017 at 22:22:55 UTC, Adam Wilson wrote:
On 10/23/17 08:21, Kagamin wrote:
[...]
Actually I think it fits perfectly with D, not for reason of
performance, but for
On 10/23/17 17:27, flamencofantasy wrote:
On Monday, 23 October 2017 at 22:22:55 UTC, Adam Wilson wrote:
On 10/23/17 08:21, Kagamin wrote:
[...]
Actually I think it fits perfectly with D, not for reason of
performance, but for reason of flexibility. D is a polyglot language,
with by far the
On Monday, 23 October 2017 at 22:22:55 UTC, Adam Wilson wrote:
On 10/23/17 08:21, Kagamin wrote:
[...]
Actually I think it fits perfectly with D, not for reason of
performance, but for reason of flexibility. D is a polyglot
language, with by far the most number of methodologies
supported
On Monday, 23 October 2017 at 22:22:55 UTC, Adam Wilson wrote:
Additionally, MSFT/C# fully recognizes that the benefits of
Async/Await have never been and never were intended to be for
performance. Async/Await trades raw performance for an ability
to handle a truly massive number of
On 10/23/17 08:21, Kagamin wrote:
On Friday, 20 October 2017 at 09:49:34 UTC, Adam Wilson wrote:
Others are less obvious, for example, async/await is syntax sugar for
a collection of Task-based idioms in C#.
Now I think it's doesn't fit D. async/await wasn't made for performance,
but for
On Monday, 23 October 2017 at 21:14:18 UTC, bauss wrote:
On Monday, 23 October 2017 at 12:48:33 UTC, Atila Neves wrote:
On Monday, 23 October 2017 at 09:13:45 UTC, Satoshi wrote:
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
[...]
Whats about this one?
auto foo = 42;
auto
On Monday, 23 October 2017 at 12:48:33 UTC, Atila Neves wrote:
On Monday, 23 October 2017 at 09:13:45 UTC, Satoshi wrote:
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
[...]
Whats about this one?
auto foo = 42;
auto bar = "bar";
writeln(`Foo is {foo} and bar is {bar}`);
On 10/18/2017 1:56 AM, Satoshi wrote:
Unable to publish closed source library without workaround and ugly PIMPL
design.
Consider this:
--- file s.d
struct S {
int x;
this(int x) { this.x = x; }
int getX() { return x; }
}
--- file s.di
On Monday, 23 October 2017 at 11:02:41 UTC, Martin Nowak wrote:
In C++ incremental rebuilds are simple as you compile each file
individually anyhow, but that's the crux for why C++
compilations are so slow in the first place.
Compiling multiple modules at once provides lots of speedups as
On Monday, 23 October 2017 at 11:21:13 UTC, Martin Nowak wrote:
On Saturday, 21 October 2017 at 18:52:15 UTC, bitwise wrote:
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
async/await (vibe.d is nice but useless in comparison to C#
or js async/await idiom)
Reference
On Friday, 20 October 2017 at 09:49:34 UTC, Adam Wilson wrote:
Others are less obvious, for example, async/await is syntax
sugar for a collection of Task-based idioms in C#.
Now I think it's doesn't fit D. async/await wasn't made for
performance, but for conservation of thread resources,
On Monday, 23 October 2017 at 11:39:58 UTC, Martin Nowak wrote:
On Monday, 23 October 2017 at 11:23:18 UTC, Guillaume Piolat
wrote:
Not anymore, you can use the "export" keyword for Windows (eg
with LDC >= 1.2).
With what semantic?
We used to require .def files, and now use "export"
On Monday, 23 October 2017 at 11:02:41 UTC, Martin Nowak wrote:
On Monday, 23 October 2017 at 06:05:50 UTC, drug wrote:
20.10.2017 17:46, Martin Nowak пишет:
My 2 cent:
1. dub needs ability to work with other repository than
standard ones.
You mount or clone whatever you want and use `dub
On Monday, 23 October 2017 at 09:13:45 UTC, Satoshi wrote:
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
Hi,
I had been using D for almost 6 years and I want to share my
opinion with you.
I don't want to blame anyone but I'll focus more on bad things
and possible improvements.
On Friday, 20 October 2017 at 15:38:53 UTC, Martin Nowak wrote:
Commercial usage, shared libraries and stuff
There isn't any handy tool to download, manage and publish
closed source stuff.
dub is great for simple solutions but useless in big projects
with multiple targets, configurations, etc.
23.10.2017 14:02, Martin Nowak пишет:
On Monday, 23 October 2017 at 06:05:50 UTC, drug wrote:
20.10.2017 17:46, Martin Nowak пишет:
My 2 cent:
1. dub needs ability to work with other repository than standard ones.
You mount or clone whatever you want and use `dub add-local`.
This is
On Monday, 23 October 2017 at 09:13:45 UTC, Satoshi wrote:
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
Hi,
I had been using D for almost 6 years and I want to share my
opinion with you.
I don't want to blame anyone but I'll focus more on bad things
and possible improvements.
On Monday, 23 October 2017 at 11:23:18 UTC, Guillaume Piolat
wrote:
Not anymore, you can use the "export" keyword for Windows (eg
with LDC >= 1.2).
With what semantic?
Every-symbol-public-by-default in Posix is annoying though :)
We agreed on hidden visibility by default for everything
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
dub is great for simple solutions but useless in big projects
with multiple targets, configurations, etc.
Works here. Closed source can be handled with path-based
dependencies and private checkouts.
Configurations are handled
On Saturday, 21 October 2017 at 18:52:15 UTC, bitwise wrote:
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
async/await (vibe.d is nice but useless in comparison to C# or
js async/await idiom)
Reference counting when we cannot use GC...
If I understand correctly, both of
On Sunday, 22 October 2017 at 22:00:19 UTC, bitwise wrote:
I hope resumable functions for for generator/coroutine style
usage are also part of the plan. Allocator support would be
nice too.
Please see
https://forum.dlang.org/post/pbnthucxpvbgzzuig...@forum.dlang.org
for how this could be
On Monday, 23 October 2017 at 11:02:41 UTC, Martin Nowak wrote:
In C++ incremental rebuilds are simple as you compile each file
individually anyhow, but that's the crux for why C++
compilations are so slow in the first place.
Compiling multiple modules at once provides lots of speedups as
you
On Monday, 23 October 2017 at 06:05:50 UTC, drug wrote:
20.10.2017 17:46, Martin Nowak пишет:
My 2 cent:
1. dub needs ability to work with other repository than
standard ones.
You mount or clone whatever you want and use `dub add-local`.
2. multicore building - entire project in D builds
On Monday, 23 October 2017 at 10:42:35 UTC, drug wrote:
Also such build system should provide a way to build C/C++ (and
others) codebase or let other build systems build D codebase,
using generated makefile for example.
In fact dub can generate cmake files, more generators for e.g.
ninja or
23.10.2017 12:58, bauss пишет:
On Monday, 23 October 2017 at 06:05:50 UTC, drug wrote:
20.10.2017 17:46, Martin Nowak пишет:
On Thursday, 19 October 2017 at 06:50:12 UTC, Fra Mecca wrote:
We miss a build system that is tailored towards enterprises
Anything more specific on that?
My 2
On 23/10/2017 10:58 AM, bauss wrote:
On Monday, 23 October 2017 at 06:05:50 UTC, drug wrote:
20.10.2017 17:46, Martin Nowak пишет:
On Thursday, 19 October 2017 at 06:50:12 UTC, Fra Mecca wrote:
We miss a build system that is tailored towards enterprises
Anything more specific on that?
My
On Monday, 23 October 2017 at 06:05:50 UTC, drug wrote:
20.10.2017 17:46, Martin Nowak пишет:
On Thursday, 19 October 2017 at 06:50:12 UTC, Fra Mecca wrote:
We miss a build system that is tailored towards enterprises
Anything more specific on that?
My 2 cent:
1. dub needs ability to work
On Monday, 23 October 2017 at 09:13:45 UTC, Satoshi wrote:
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
Hi,
I had been using D for almost 6 years and I want to share my
opinion with you.
I don't want to blame anyone but I'll focus more on bad things
and possible improvements.
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
Hi,
I had been using D for almost 6 years and I want to share my
opinion with you.
I don't want to blame anyone but I'll focus more on bad things
and possible improvements.
And this is just how I see D from my perspective.
(Sorry
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
[...]
The language for sure is huge and complicated and adding new
features will only make it grow bigger. I'm not saying we
shouldn't add any new features. It is important to have the right
defaults to gain the critical mass for
20.10.2017 17:46, Martin Nowak пишет:
On Thursday, 19 October 2017 at 06:50:12 UTC, Fra Mecca wrote:
We miss a build system that is tailored towards enterprises
Anything more specific on that?
My 2 cent:
1. dub needs ability to work with other repository than standard ones.
2. multicore
On Saturday, 21 October 2017 at 21:31:45 UTC, Walter Bright wrote:
On 10/21/2017 1:40 PM, Adam Wilson wrote:
Walter has stated numerous times both here and at conferences
that Async/Await is definitely a goal.
Async/Await can be implemented by rewriting ("lowering") the
code to simpler D
On Sunday, 22 October 2017 at 15:07:10 UTC, meppl wrote:
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
syntactic sugar for:
tuples
as far as i know there was the will to implement tuples in the
language, but there is still a deprecation in the way:
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
syntactic sugar for:
tuples
as far as i know there was the will to implement tuples in the
language, but there is still a deprecation in the way:
https://dlang.org/deprecate.html#Using%20the%20result%20of%20a%20comma%20expression
On Sunday, 22 October 2017 at 07:23:14 UTC, meppl wrote:
On Sunday, 22 October 2017 at 01:02:06 UTC, EntangledQuanta
wrote:
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
...
ps, also i want something similar to this in D:
new Foo() {
property1 = 42,
property2 = "bar"
};
On Sunday, 22 October 2017 at 01:02:06 UTC, EntangledQuanta wrote:
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
...
These guys are old now and don't have the drive they used to
have. It happens, part of life. Unfortunately they do not
realize this and do not want to pass
On 10/20/2017 11:11 AM, Adam D. Ruppe wrote:
On Friday, 20 October 2017 at 16:36:28 UTC, jmh530 wrote:
It might help to have some sense of how the main devs time on D is being used.
Definitely, I currently have no clue what they are on.
Whiling away the hours, conferring with the flowers,
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
Hi,
I had been using D for almost 6 years and I want to share my
opinion with you.
I don't want to blame anyone but I'll focus more on bad things
and possible improvements.
And this is just how I see D from my perspective.
(Sorry
On Saturday, 21 October 2017 at 21:45:11 UTC, Adam D. Ruppe wrote:
On Saturday, 21 October 2017 at 20:02:28 UTC, user1234 wrote:
I'm not sure that people talked much about the elvis operator
(which was introduced in the topic by M.Nowak). In the first
message were mentioned the null
On Saturday, 21 October 2017 at 20:02:28 UTC, user1234 wrote:
I'm not sure that people talked much about the elvis operator
(which was introduced in the topic by M.Nowak). In the first
message were mentioned the null coalescence operator "??"
What's the difference between `?:` and `??`?
As
On 10/21/2017 1:40 PM, Adam Wilson wrote:
Walter has stated numerous times both here and at conferences that Async/Await
is definitely a goal. However, it's not as high a priority as the @safe/@nogc
work so it hasn't made it to any official vision statement. Also I just talked
to him offline
On 10/21/17 11:52, bitwise wrote:
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
async/await (vibe.d is nice but useless in comparison to C# or js
async/await idiom)
Reference counting when we cannot use GC...
If I understand correctly, both of these depend on
On Saturday, 21 October 2017 at 19:39:31 UTC, Andrei Alexandrescu
wrote:
[...]
Using the topic of the Elvis operator as a running example, a
good DIP would contain motivation such as:
* Present evidence of the successful use of ?: in other
languages
I'm not sure that people talked much
On 10/21/17 9:47 AM, Martin Nowak wrote:
On Friday, 20 October 2017 at 18:11:50 UTC, Adam D. Ruppe wrote:
On Friday, 20 October 2017 at 16:36:28 UTC, jmh530 wrote:
It might help to have some sense of how the main devs time on D is
being used.
Definitely, I currently have no clue what they
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
async/await (vibe.d is nice but useless in comparison to C# or
js async/await idiom)
Reference counting when we cannot use GC...
If I understand correctly, both of these depend on implementation
of 'scope' which is being
On Friday, 20 October 2017 at 22:25:20 UTC, Adam Wilson wrote:
For example, ?? and ?. are ridiculously common idioms that we
all perform every day in our D code. And as Mr. Ruppe rightly
pointed out, it'd probably take about an hour each to knock
together a complete PR for these features.
On Friday, 20 October 2017 at 18:11:50 UTC, Adam D. Ruppe wrote:
On Friday, 20 October 2017 at 16:36:28 UTC, jmh530 wrote:
It might help to have some sense of how the main devs time on
D is being used.
Definitely, I currently have no clue what they are on.
Tried that, didn't resonate that
On Friday, 20 October 2017 at 20:05:51 UTC, jmh530 wrote:
Interesting proposals, but IMHO, the only ESSENTIAL feature
missing in D is the possibility to program in D using a
built-in reference-counting based variant of the standard
library.
Look at the goals for H2 2017
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
Hi,
I had been using D for almost 6 years and I want to share my
opinion with you.
I don't want to blame anyone but I'll focus more on bad things
and possible improvements.
And this is just how I see D from my perspective.
(Sorry
On Friday, October 20, 2017 15:25:20 Adam Wilson via Digitalmars-d wrote:
> So far I have seen three arguments proffered for the ban syntax sugar.
>
> The first is "Walter/Andrei doesn't have the time."
That actually has pretty much nothing to do with a feature request like
syntactic sugar -
On Friday, 20 October 2017 at 22:25:20 UTC, Adam Wilson wrote:
On 10/20/17 04:04, Jonathan M Davis wrote:
On Friday, October 20, 2017 02:49:34 Adam Wilson via
Digitalmars-d wrote:
Preach
On 10/20/17 04:04, Jonathan M Davis wrote:
On Friday, October 20, 2017 02:49:34 Adam Wilson via Digitalmars-d wrote:
Here is the thing that bothers me about that stance. You are correct,
but I don't think you've considered the logical conclusion of the
direction your argument is headed. Pray
On Friday, 20 October 2017 at 20:11:46 UTC, jmh530 wrote:
On Friday, 20 October 2017 at 19:54:09 UTC, user1234 wrote:
On Friday, 20 October 2017 at 18:11:50 UTC, Adam D. Ruppe
wrote:
[...] The elvis operator, while trivial and
unnecessary, would be easy to implement correctly and give
a nice
On Friday, 20 October 2017 at 19:54:09 UTC, user1234 wrote:
On Friday, 20 October 2017 at 18:11:50 UTC, Adam D. Ruppe wrote:
[...] The elvis operator, while trivial and
unnecessary, would be easy to implement correctly and give
a nice little PR boost to show that we care about the people
On Friday, 20 October 2017 at 19:18:15 UTC, Ecstatic Coder wrote:
Interesting proposals, but IMHO, the only ESSENTIAL feature
missing in D is the possibility to program in D using a
built-in reference-counting based variant of the standard
library.
Look at the goals for H2 2017
On Friday, 20 October 2017 at 18:11:50 UTC, Adam D. Ruppe wrote:
[...] The elvis operator, while trivial and
unnecessary, would be easy to implement correctly and give
a nice little PR boost to show that we care about the people
talking about it.
If you go by there, the safe navigation
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
Hi,
I had been using D for almost 6 years and I want to share my
opinion with you.
I don't want to blame anyone but I'll focus more on bad things
and possible improvements.
And this is just how I see D from my perspective.
(Sorry
On Fri, Oct 20, 2017 at 06:20:52PM +, Random D user via Digitalmars-d wrote:
> On Friday, 20 October 2017 at 02:20:31 UTC, Adam D. Ruppe wrote:
> > On Friday, 20 October 2017 at 00:26:19 UTC, bauss wrote:
> > > return foo ?? null; would be so much easier.
> > return getOr(foo, null);
>
> I
On Friday, 20 October 2017 at 02:20:31 UTC, Adam D. Ruppe wrote:
On Friday, 20 October 2017 at 00:26:19 UTC, bauss wrote:
return foo ?? null; would be so much easier.
return getOr(foo, null);
I guess with UFCS you could get:
return foo.PP(null); // vs.
return foo ?? null;
:D
On Friday, 20 October 2017 at 16:36:28 UTC, jmh530 wrote:
It might help to have some sense of how the main devs time on D
is being used.
Definitely, I currently have no clue what they are on.
Is elvis operator more important than improving
safe/scope/nogc/etc, I think most would say no.
I
On Friday, 20 October 2017 at 15:38:53 UTC, Martin Nowak wrote:
Something I want to have for quite a while is a free-form poll
for features, maybe running 2 weeks or so, to get a better
understanding of community priorities.
Maybe once a quarter, ;)
It might help to have some sense of
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
First, D started as a great new language with the best from all
languages. But now D seems more and more conservative. New
syntactic sugars aren't added just because they can be found in
phobos. (this was Walter's answer when I
On Friday, 20 October 2017 at 08:09:59 UTC, Satoshi wrote:
> return foo ?? null; would be so much easier.
Definitely the Elvis operator is a small and sometimes useful
addition.
https://en.wikipedia.org/wiki/Elvis_operator
Your best bet on getting it, is writing a small DIP, the organize
On Thursday, 19 October 2017 at 06:50:12 UTC, Fra Mecca wrote:
We miss a build system that is tailored towards enterprises
Anything more specific on that?
On Friday, 20 October 2017 at 00:26:19 UTC, bauss wrote:
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
conditional dereferencing and stuff about that (same as in C#)
foo?.bar;
foo?[bar];
return foo ?? null;
Tbh. these are some I really wish were in D, because it becomes
On Friday, 20 October 2017 at 09:40:26 UTC, Satoshi wrote:
If you need reason why is writing less code better just
calculate the time of it.
getOne(foo, null) // costs 3 sec.
foo ?? null // cost 1 sec.
Note that I do NOT object to these additions. I think they'd be
trivial, backward
1 - 100 of 153 matches
Mail list logo
