On Wed, 30 Jan 2019 09:15:36 -0800, Manu wrote:
> Why are you so stuck on this case? The DIP is about accepting rvalues,
> not lvalues...
> Calling with 'p', an lvalue, is not subject to this DIP.
The result of a CastExpression is an rvalue. An implicit cast is a
compiler-inserted
On Tue, 29 Jan 2019 21:13:17 +, WebFreak001 wrote:
> dub.sdl:
> name "my-awesome-gtk-app"
>
> dependency "gtk-d" version="~>3.8.5"
Might I recommend instead:
dependency "gtk-d" version="3.8.5"
This depends on gtk-d 3.8.5 and only that version. If there is a breaking
change in 3.8.6
On Fri, 25 Jan 2019 18:14:56 -0800, Manu wrote:
> Removing the `void` stuff end expanding such that the declaration +
> initialisation is at the appropriate moments; any function can throw
> normally, and the unwind works naturally?
The contention was that, if the arguments are constructed
On Fri, 25 Jan 2019 23:08:52 +, kinke wrote:
> On Friday, 25 January 2019 at 19:08:55 UTC, Walter Bright wrote:
>> On 1/25/2019 2:57 AM, kinke wrote:
>>> On Thursday, 24 January 2019 at 23:59:30 UTC, Walter Bright wrote:
On 1/24/2019 1:03 PM, kinke wrote:
> (bool __gate = false;) ,
On Wed, 23 Jan 2019 14:37:30 +, Bienlein wrote:
> This is all true, but you need to keep in mind that Go had no real
> package manager for a long time. There was the "go get" command which
> loaded the code from some github repo in the state it was at the time
> when being loaded. There was no
On Fri, 18 Jan 2019 11:43:58 -0800, H. S. Teoh wrote:
> (1) it often builds unnecessarily -- `touch source.d` and it rebuilds
> source.d even though the contents haven't changed; and
Timestamp-based change detection is simple and cheap. If your filesystem
supports a revision id for each file,
On Tue, 15 Jan 2019 11:59:58 +, Atila Neves wrote:
> He's not saying "kill classes in D", he's saying an OOP system in D
> could be implemented from primitives and classes don't need to be a
> language feature, similar to CLOS in Common Lisp.
As long as the syntax and behavior don't change,
On Mon, 14 Jan 2019 21:12:48 +, Paul Backus wrote:
> On Monday, 14 January 2019 at 21:08:50 UTC, Ben Jones wrote:
>> Is it possible to declare a function whose name is a CTFE computed
>> string?
>
> Yes, if you do it with a string mixin.
And more simply, you can declare a function with a
On Sun, 13 Jan 2019 21:40:43 +, Murilo wrote:
> It would be a good idea to publish that on the facebook group for users
> of D. There you would be able to spread the information fast. It is
> called Programming in D. Here is the link:
> https://www.facebook.com/groups/662119670846705/
I think
On Thu, 20 Dec 2018 14:19:33 +0100, Daniel Kozak wrote:
> default(attributes..) is no needed. You can already do this by:
>
> pure @safe:
> // your code
That doesn't work if you have any member functions, and Walter says it's
unlikely that that will ever change, even with a DIP.
default(pure)
On Wed, 19 Dec 2018 17:28:01 +, Vijay Nayar wrote:
> Could you please elaborate a little bit more on this? In the linked
> program, I had expected that "ref" would return a reference to "a" that
> would behave similar to a pointer.
They work like pointers that automatically dereference when
On Wed, 19 Dec 2018 01:04:24 +, Nathan S. wrote:
> On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote:
>> Not the case in Rust, not the case in how I write D. TBH it's not such
>> a big deal because something has to be typed, I just default to const
>> now anyway instead of auto.
On Tue, 18 Dec 2018 08:17:28 +, Russel Winder wrote:
> I did a lightning talk at the GStreamer conference in Edinburgh a couple
> of months ago, concluding that I think D (which about half the audience
> knew of) is overall better than Rust for GTK+ and GStreamer
> applications, but
On Sun, 16 Dec 2018 00:17:55 +, Paul Backus wrote:
> On Wednesday, 12 December 2018 at 22:41:50 UTC, H. S. Teoh wrote:
>> It's time we came back to the essentials. Current monolithic build
>> systems ought to be split into two parts: [...]
> You're missing (0) the package manager, which is
On Sat, 15 Dec 2018 21:09:12 +, Sebastiaan Koppe wrote:
> On Saturday, 15 December 2018 at 15:37:19 UTC, Basile B. wrote:
>> I think this is what Walter calls "AST poisoning" (never understood how
>> it worked before today). And the whole parser is like this.
>>
>> This poisoning kills the
On Sat, 15 Dec 2018 00:43:42 +, j...@jjs.com wrote:
>>> Do you have plans to incorportae this as a VisualD project .csproj
Retaining the "On Sat, 15 Dec, Person A wrote:" lines is helpful for
keeping track of the conversation.
> Using DLangInNet(I'm renamed your project for you ;)
Only the
On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe
wrote:
Though, I think we could also get a lot of mileage out of
fixing two glaring problems with the status quo: 1) making
attr: at the top descend into aggregates consistently and 2)
LETTING US TURN THEM OFF. SERIOUSLY WHY DON'T WE
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
I think there’s a general consensus that @safe, pure and
immutable should be default.
I recall there was a decent chunk of people around D2.007 who
were pushing for const-by-default function parameters on the
grounds of if
On Wednesday, 12 December 2018 at 22:41:50 UTC, H. S. Teoh wrote:
And here is the crux of my rant about build systems (earlier in
this thread). There is no *technical reason* why build systems
should be constricted in this way. Today's landscape of
specific projects being inextricably tied to
On Mon, 10 Dec 2018 13:01:08 -0800, H. S. Teoh wrote:
> It also requires network access. On *every* invocation, unless
> explicitly turned off. And even then, it performs time-consuming
> dependency resolutions on every invocation, which doubles or triples
> incremental build times. Again,
On Tue, 11 Dec 2018 02:54:15 +, Mike Franklin wrote:
> Why not just write your build/tooling scripts in D? That's what I
> prefer to do, and there's been a recent effort to do just that for the
> DMD compiler as well:
> https://github.com/dlang/dmd/blob/master/src/build.d It still resembles
On Mon, 10 Dec 2018 21:53:40 +, GoaLitiuM wrote:
> The results for touching second file seems like an anomaly to me,
The generated ninja file had one rule per source file. If your modules
tend to import each other a lot, or if they transitively import the code
that's doing expensive stuff,
On Mon, 03 Dec 2018 15:08:33 +, greatsam4sure wrote:
> It will be nice if you can port this code base to vs code. It is the
> same visual studio code base.
Pardon? VS Code is an Electron application written mainly in TypeScript,
while Visual Studio is a Windows application written in C++ and
On Wed, 14 Nov 2018 13:40:46 -0500, Steven Schveighoffer wrote:
> You don't think this is confusing?
>
> enum A : int {
> val
> }
>
> A a;
> foo(a); // error: be more specific
> int x = a;
> foo(x); // Sure
I find this confusing:
void foo(int i) {}
void foo(ubyte b) {}
enum A
On Tue, 13 Nov 2018 20:27:05 -0800, Walter Bright wrote:
> There have been various attempts over the years to "fix" various things
> in the D matching system by adding "just one more" match level.
I kind of feel like, if something would be confusing like this, maybe the
compiler shouldn't be
On Wed, 14 Nov 2018 12:09:33 +0100, Jacob Carlborg wrote:
> What is ": int" doing, only specifying the size?
It specifies the type to match for overloading when the compiler isn't
required by the language to constant-fold the value.
On Wed, 14 Nov 2018 00:43:54 +, Rubn wrote:
> I wonder what these examples are? What did C++ do instead, cause
> something tells me it didn't do what D is doing. An enum in C++ doesn't
> call different function overloads based on the constant value.
Long long and unsigned long long give an
On Tue, 13 Nov 2018 17:53:27 +, 12345swordy wrote:
> Ok, now that has got to be a bug. If you explicit cast the number to an
> integer then you expect the overload function with int to be called.
>
> -Alex
...my mistake, I can't reproduce that anymore. Pretend I didn't say
anything.
On Tue, 13 Nov 2018 09:46:17 -0500, Steven Schveighoffer wrote:
> Maybe the biggest gripe here is that enums don't prefer their base types
> over what their base types convert to. In the developer's mind, the
> conversion is:
>
> A => int => (via VRP) short
>
> which seems more complex than just
On Tue, 13 Nov 2018 00:28:46 +, Isaac S. wrote:
> Sorry if it wasn't clear, I meant that if `enum Foo : some_int_type`
> makes it so some_int_type is preferred (because it's a more direct
> conversion) DScanner could warn anyone that just does `enum Foo`.
Sorry, I read too hastily and thought
On Tue, 13 Nov 2018 00:08:04 +, Isaac S. wrote:
> If you really want this plaque in the language, at least make it not
> affect those that gave their enum a type. If you at least do that,
> someone can add it to DScanner to tell anyone that doesn't type their
> enum to expect illogical
On Mon, 12 Nov 2018 14:07:39 -0800, Walter Bright wrote:
> => conversion>
>=> conversion>
One confusion is from value range propagation / constant folding reaching
past the static type information to yield a different result from what
static typing alone
On Mon, 12 Nov 2018 20:34:11 +, Neia Neutuladh wrote:
> enum : int { a = 0 }
> enum A : int { a = 0 }
> f(a); // calls the int overload f(A.a); // calls the bool overload
>
> Tell me more about this "consistency".
Filed issue 19394. (Sorry for spam.)
On Mon, 12 Nov 2018 09:45:14 +, Mike Parker wrote:
> From Example B in the DIP:
>
> ```
> int f(bool b) { return 1; }
> int f(int i) { return 2; }
>
> enum E : int {
> a = 0,
> b = 1,
> c = 2,
> }
> ```
>
> Here, f(a) and f(b) call the bool overload, while f(c) calls the int
On Mon, 12 Nov 2018 14:10:42 -0500, Steven Schveighoffer wrote:
> But it's not consistent:
And std.traits.isIntegral has not considered bools integral since its
initial creation in 2007. Both Walter and Andrei have mucked about with
that code and saw no reason to change it, even in wild and
On Thu, 08 Nov 2018 18:38:55 +, welkam wrote:
> On Thursday, 8 November 2018 at 18:15:55 UTC, Stanislav Blinov wrote:
>>
>> One keystroke (well ok, two keys because it's *) ;)
>> https://dl.dropbox.com/s/mifou0ervwspx5i/vimhl.png
>>
>>
> What sorcery is this? I need to know. I guess its vim
On Thu, 08 Nov 2018 18:13:55 +0100, Jacob Carlborg wrote:
> I guess we have very different ideas on what "small scope" is. For me it
> means around 10 lines. Here's an example in the DMD code base, the
> method for doing the semantic analyze on a call expression [1]. It's 902
> lines long and has
On Thu, 08 Nov 2018 14:35:29 +1300, rikki cattermole wrote:
> Its a symptom of a larger set of problems. The frontend is not quite
> ready to have the GC turned on full time.
>
> Based upon my testing, that little memory leak prevents pretty much
> *all* memory allocated by the GC to not be
On Thu, 08 Nov 2018 01:49:49 +1300, rikki cattermole wrote:
> On 08/11/2018 1:46 AM, Patrick Schluter wrote:
>> Now that the compiler is completely in D, wouldn't it be a good idea to
>> activate the GC in the compiler. I know that it requires some care for
>> bootstrapping the compiler when there
On Mon, 05 Nov 2018 01:23:44 +, nobodycares wrote:
> I think there are more than enough real-world examples, of where issues
> around 'type safety', or lack of, have caused a sufficient number of
> bugs, to warrant a discussion about ways to further improve type safety.
You do realize we can
On Sun, 04 Nov 2018 11:36:39 +, FooledDonor wrote:
> Can we argue about the problems arising from the potential introduction
> of this feature?
There are many potential features that wouldn't cause problems in
isolation. Should we add all of them? Obviously not; the result would be a
On Sat, 03 Nov 2018 11:24:06 +, FooledDonor wrote:
> And if the validity of a person's reasoning is a function of his way of
> expressing them, well ... do not pose to software engineers at least
If you want other people to do work for you, you need to convince them to
do it. This is an open
On Sat, 03 Nov 2018 04:50:52 +, unprotected-entity wrote:
> (q1) Why is it, that people who use D, object *so much* to the idea of
> allowing (at the choice of the programmer) for a type to have it's own
> private state *within* a module (so that its private state is respected
> by other code
On Thu, 01 Nov 2018 22:37:59 +, unprotected-entity wrote:
> On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote:
>>
>> Actually, code within a module *should* be tightly coupled and cohesive
>> -- that's the whole reason to put that code inside a single module in
>> the first place.
On Mon, 29 Oct 2018 03:43:49 +, Mike Parker wrote:
> Congratulations are in order for Iain Buclaw. His efforts have been
> rewarded in a big way. Last Friday, he got the greenlight to move
> forward with submitting his changes into GCC:
Awesome!
What frontend version is this, out of
On Sat, 27 Oct 2018 10:54:30 +, Joakim wrote:
> I see, so you want other taxpayers to bail you out for your mistakes,
> interesting.
One of the major points of having a government is to create these
regulations that make it less likely for individuals to suffer from the
actions of other
On Fri, 26 Oct 2018 06:19:29 +, Joakim wrote:
> On Friday, 26 October 2018 at 05:47:05 UTC, Neia Neutuladh wrote:
>> On Fri, 26 Oct 2018 02:38:08 +, Joakim wrote:
>>> As with D, sometimes the new _is_ better, so perhaps you shouldn't
>>> assume old is better either.
>>
>> There's no
On Fri, 26 Oct 2018 02:38:08 +, Joakim wrote:
> As with D, sometimes the new _is_ better, so perhaps you shouldn't
> assume old is better either.
There's no assuming going on. Cryptocurrencies are worse than credit cards
for everything that normal people care about, and they're better than
On Wednesday, 17 October 2018 at 14:02:20 UTC, Jesse Phillips
wrote:
Wait, why does each get a special bailout? Doesn't until full
that role?
`until` is lazy. We could have `doUntil` instead, which would be
eager and would return a boolean indicating whether to continue.
We could all write
On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole
wrote:
Here is a question (that I don't think has been asked) why not
@copy?
It's not wrong to call this an implicit constructor since it's
called implicitly. It also means that, if we get implicit
constructors in general, we
On Sunday, 9 September 2018 at 09:34:31 UTC, Nick Sabalausky
(Abscissa) wrote:
1. As most United States citizens are implicitly aware (though
the government assumes NO responsibility to ensure citizens are
aware of this), to vote in a United States of America election
and have the vote legally
On Monday, 25 December 2017 at 08:57:09 UTC, Jacob Carlborg wrote:
If I knew exactly what would need to be done I would most
likely have done it already :). Perhaps Martin that implemented
the support on Linux or David that, I think, implemented it for
LDC on macOS would be better suited for
On Tuesday, 19 December 2017 at 21:38:40 UTC, Mike Wey wrote:
And for GtkD, that is why it would make sense to relay on the
packages supplied by your distribution. And just list "gtkd-3"
in the "libs" section. Avoiding the need for the workaround to
build a shared version.
That would be
On Monday, 18 December 2017 at 09:03:09 UTC, Andrea Fontana wrote:
I think you should add some way to translate days/month in
other language.
That would be great! Unfortunately, it requires a decent locales
library.
From the "it's a hacky workaround but it's what we've got"
department: how to use dynamic libraries in dub, with GtkD as the
example.
GtkD takes about 45MB on its own, and that means it can take a
fair bit of time to build anything that depends on it -- even if
it only uses a handful of
# Sales pitch
If you've ever had to parse datetime input from multiple sources
and everyone's standardized on ISO8601, you might have found out
that that's not quite as standard as you'd wish. This is where
datefmt helps you.
---
import datefmt;
auto expected = SysTime(Date(2010, 1, 1),
On Saturday, 5 August 2017 at 22:43:31 UTC, WebFreak001 wrote:
I just released a beta version on the visual studio marketplace
that allows you to try out the latest features of serve-d.
Awesome! Once I worked around the binary placement issue, this
actually gave me completion options, which
57 matches
Mail list logo
