On Wednesday, 18 August 2021 at 05:33:13 UTC, james.p.leblanc
wrote:
If I wanted to ensure that a function accepts only arguments of
byte, int, uint, long, etc. (i.e. integer-like types). Is the
accepted way to do this like so?:
**auto foo( T : long )(T a, T b){ ... }**
I very much prefer
On Wednesday, 5 May 2021 at 11:54:51 UTC, user1234 wrote:
On Wednesday, 5 May 2021 at 10:01:13 UTC, user1234 wrote:
Maybe some time in future, but for now there is a lot more
priority stuff to do before even attempting this.
Thanks for the explanations. BTW I had the same question for
LDC
On Wednesday, 5 May 2021 at 10:01:13 UTC, user1234 wrote:
I have a technical question about the tool itself. It is mostly
written in cpp.
Oh dear!
Isn't it possible to use it to translate itself into D?
On Tuesday, 9 February 2021 at 21:00:39 UTC, Paul Backus wrote:
On Tuesday, 9 February 2021 at 19:53:27 UTC, Temtaime wrote:
pure is broken. Just don't [use it]
Allowing memory allocation in pure code in a language that can
distinguish between pointer equality and value equality is,
let's
On Saturday, 10 October 2020 at 19:51:10 UTC, DMon wrote:
This is where I'm at:
import std.stdio;
import std.conv;
// StdioException
// ConvException
// StringException
// ErrnoException
// FormatException
// UnicodeException
// UTFException
// FileMissingException
// DataCorruptionException
On Wednesday, 16 September 2020 at 07:38:26 UTC, Dominikus Dittes
Scherkl wrote:
We only need to define which properties a character need to be
allowed in an identifier.
I think the following change in the grammar would be sufficient:
Identifier:
IdentifierStart
IdentifierStart
On Wednesday, 16 September 2020 at 00:22:15 UTC, Steven
Schveighoffer wrote:
Someone should verify that the character you want to use for a
symbol name is actually considered a letter or not. Using
phobos to prove this is kind of self-defeating, as I'm pretty
sure it would be in league with
On Tuesday, 15 September 2020 at 06:49:08 UTC, Jon Degenhardt
wrote:
On Tuesday, 15 September 2020 at 02:23:31 UTC, Paul Backus
wrote:
Identifiers start with a letter, _, or universal alpha, and
are followed by any number of letters, _, digits, or universal
alphas. Universal alphas are as
On Tuesday, 8 September 2020 at 13:28:22 UTC, Cecil Ward wrote:
int xcoord;
int ycoord;
You can define your own types, of course:
struct xcoord { int x; alias x this; }
struct ycoord { int y; alias y this; }
void myfunc(xcoord x; ycoord y, color c) {}
On Monday, 3 August 2020 at 14:50:36 UTC, Steven Schveighoffer
wrote:
On 8/3/20 5:53 AM, Martin Tschierschke wrote:
I prefer putting additional bracket around
For really long expressions you could also split it on multiple
lines:
c = (b_expression == 0)
? (d_longer_expression)
:
On Tuesday, 21 July 2020 at 20:39:54 UTC, Mario Kröplin wrote:
https://github.com/linkrope/uncovered examines coverage listing
files to identify the ones with the most uncovered lines.
Was this done with the new coverage check during CTFE?
I would expect the numbers to be better then...
On Tuesday, 14 July 2020 at 07:05:43 UTC, Arafel wrote:
*However*, for this to work, you shouldn't use `shared` member
variables unless absolutely necessary, much less whole `shared`
classes/structs
This is generally true. Avoid sharing many variables!
Tasks should be as independent from each
On Monday, 13 July 2020 at 19:32:33 UTC, Marcone wrote:
alias runas = compose!(x => to!bool((cast(int) x) > 32), x =>
ShellExecute(null, "runas", "cmd", cast(wchar*) "/c \"cd /d %s
&& %s\"".format(getcwd(), x).to!wstring, null,
SW_HIDE).WaitForSingleObject(WAIT_TIMEOUT));
runas("netsh
On Wednesday, 24 June 2020 at 09:01:28 UTC, claptrap wrote:
On Wednesday, 24 June 2020 at 00:53:58 UTC, H. S. Teoh wrote:
On Tue, Jun 23, 2020 at 11:53:36PM +, claptrap via
If your implementations are based on built-in operators, you
could use mixins to unify the implementations into
On Friday, 22 May 2020 at 18:24:39 UTC, Atila Neves wrote:
memcpy isn't a good example since it's explicitly @system
Yes, it's a good example. Because if you include any C function,
you don't know if it uses memcpy internally - except if you have
the code. And as memcpy is used heavily
On Friday, 17 April 2020 at 08:59:41 UTC, Robert M. Münch wrote:
How would that look like?
myStruct ms = void; // ???
Exactly.
On Thursday, 13 February 2020 at 22:48:32 UTC, Andre Pany wrote:
Hi,
Dieses Tutorial zeigt, wie GTK3 zum Erstellen von HTML5
Anwendungen verwendet werden kann.
http://d-land.sepany.de/tutorials/gui/html5-anwendungen-mit-gtk3-schreiben
Viele Grüße
Andre
Cool.
On Monday, 6 January 2020 at 10:07:37 UTC, WebFreak001 wrote:
I was wondering, how are you supposed to use std.file : read in
@safe code when it returns a void[] but you want to get all
bytes in the file?
Is void[] really the correct type it should be returning
instead of ubyte[] when it
On Tuesday, 10 December 2019 at 07:23:56 UTC, AA wrote:
Would the second solution of declaring a template constraint
like that be considering strange/out of place in D? e.g. do
people normally try and declare the template constraints on a
function or just rely on compile time failure from to
On Monday, 16 September 2019 at 05:22:14 UTC, Cecil Ward wrote:
I have a particular type name and that type may or may not be
const and/or immutable. How do I make a new type based on this
that is mutable, ie getting rid of both const and immutable,
but not knowing what the original type is ?
On Monday, 4 February 2019 at 17:09:25 UTC, bitwise wrote:
I think this solves all of the above:
fun(10);
==>
(int __temp0){ (return)? fun( __temp0 ); }(10);
-The expression/statement issue is solved by the closure
-The initialization issue created by the ":=" approach is not
present here
On Monday, 17 December 2018 at 22:01:07 UTC, Adam D. Ruppe wrote:
Well, I am getting back into it:
http://dpldocs.info/this-week-in-d/Blog.Posted_2018_12_17.html
Cool. Keep it going!
On Saturday, 20 October 2018 at 06:04:45 UTC, Manu wrote:
How can you find that such a construct carries its weight with
respect
to its rare-ness, when its usefulness is very limited to begin
with?
I suggested it only because of the resistance to the proposed
implicit cast to shared. But I
On Saturday, 20 October 2018 at 00:46:36 UTC, Nicholas Wilson
wrote:
Mutable = value may change
const = I will not change the value
immutable = the value will not change
unshared = I (well the current thread) owns the reference
shared = reference not owned, no unordered access, no
(unordered)
On Friday, 19 October 2018 at 15:46:20 UTC, Stanislav Blinov
wrote:
On Friday, 19 October 2018 at 13:40:54 UTC, Dominikus Dittes
Scherkl wrote:
Conflating "shared" and "threadsave" in that manner was, I
think, the biggest mistake of your proposal.
He talked about it in a previous thread, and
On Friday, 19 October 2018 at 18:11:50 UTC, Manu wrote:
On Fri, Oct 19, 2018 at 6:45 AM Dominikus Dittes Scherkl via
Digitalmars-d wrote:
On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote:
> [...] What issues am I failing to address?
[...] Another point is the part of "
On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote:
On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh wrote:
What cracks me up with Manu's proposal is that it is its
simplicity and lack of ambition that is criticized the most.
shared is a clusterfuck, according to what I gathered
On Friday, 19 October 2018 at 06:25:00 UTC, rikki cattermole
wrote:
On 19/10/2018 7:09 PM, Norm wrote:
[0]
https://github.com/rikkimax/DIPs/blob/shared/DIPs/DIP1xxx-RC2.md
This document provide no reasoning about what usecases it
supports:
Is it possible to create objects that are shared
On Tuesday, 16 October 2018 at 10:15:51 UTC, Timon Gehr wrote:
On 15.10.2018 20:46, Manu wrote:
Assuming the rules above: "can't read or write to members",
and the
understanding that `shared` methods are expected to have
threadsafe
implementations (because that's the whole point), what are
On Tuesday, 25 September 2018 at 14:28:48 UTC, FeepingCreature
wrote:
On Tuesday, 25 September 2018 at 14:15:32 UTC, Dominikus Dittes
Scherkl wrote:
template from(string moduleName)
{
mixin("import from = " ~ moduleName ~ ";");
}
class TestException(T) : from!"std.format".FormatException?
On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature
wrote:
I'm playing with a branch of DMD that would warn on unused
imports:
https://github.com/FeepingCreature/dmd/tree/feature/Issue-3507-warn-on-unused-imports
Two problems have arisen.
First:
import std.stdio;
void foo(T)() {
On Monday, 10 September 2018 at 00:56:37 UTC, void wrote:
On Sunday, 9 September 2018 at 06:32:39 UTC, Jonathan M Davis
wrote:
I downloaded 100 packages from code.dlang.org and search for
"*doc*" and "*example*"
Script updated now searches for the string "unittest" on
package directory
On Friday, 24 August 2018 at 22:16:25 UTC, Jonathan M Davis wrote:
On Friday, August 24, 2018 7:46:57 AM MDT Mike Franklin via
Digitalmars-d wrote:
On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis
wrote:
> I think that you're crazy.
No, I just see more potential in D than you do.
On Friday, 24 August 2018 at 18:34:20 UTC, Daniel N wrote:
On Friday, 24 August 2018 at 12:06:15 UTC, Anton Fediushin
wrote:
I just published it on the dub registry in public domain (I
hope Daniel Nielsen is ok with that. After all, it's just 3
lines of code)
Package page:
On Thursday, 9 August 2018 at 04:16:45 UTC, Uknown wrote:
I would like to point out that C++ does this with attributes
instead[0]. If this was an attribute instead (like
`@noreturn`), it would simplify interfacing with C++. It would
also avoid the breaking change.
[0]:
On Wednesday, 25 July 2018 at 21:59:52 UTC, Ali Çehreli wrote:
Somebody had posted an article here on how well different
languages matched certain requirements of a certain coding
safety standards.
I remember D was doing pretty well and I think Ada (or SPARK?)
was included as well. What
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
This is the feedback thread for the first round of Community
Review for DIP 1016, "ref T accepts r-values":
https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md
+1
The DIP reduces bloat,
On Wednesday, 18 July 2018 at 17:49:19 UTC, H. S. Teoh wrote:
On Wed, Jul 18, 2018 at 11:30:21AM -0600, Jonathan M Davis via
On the other hand, if opCmp is allowed to return a user-defined
type, it would solve the problem in a neat way: just define a
quaternary type that encapsulates the
On Wednesday, 18 July 2018 at 17:30:21 UTC, Jonathan M Davis
wrote:
On Tuesday, July 17, 2018 21:18:12 John Colvin via
Digitalmars-d wrote:
Just do what std.typecons.Proxy does and return float.nan for
the incomparable case.
Since when is that legal? I thought that it was required for
opCmp
On Wednesday, 18 July 2018 at 13:12:05 UTC, Ivan Kazmenko wrote:
On Tuesday, 17 July 2018 at 21:18:12 UTC, John Colvin wrote:
Just do what std.typecons.Proxy does and return float.nan for
the incomparable case.
Isn't it slow though on current processors? I just threw
together a test
On Tuesday, 17 July 2018 at 21:18:12 UTC, John Colvin wrote:
On Tuesday, 17 July 2018 at 18:21:26 UTC, H. S. Teoh wrote:
But opCmp turns out to be a tarpit. Here's why:
According to the original claim, it should also return 0, for
"incomparable". However, this leads to problems:
On Thursday, 19 April 2018 at 08:20:02 UTC, Giles Bathgate wrote:
On Wednesday, 18 April 2018 at 21:04:53 UTC, Jordan Wilson
wrote:
Thinking seems sound, although having a name starting with
"get" does have the advantage of being more related to the
existing get.
Ah yes, good point. I think
On Saturday, 17 March 2018 at 18:36:35 UTC, Jonathan wrote:
On Tuesday, 19 January 2016 at 23:36:14 UTC, Adam D. Ruppe
wrote:
On Tuesday, 19 January 2016 at 22:12:06 UTC, Soviet Friend
wrote:
I don't care if my computer needs to do math on a 4 byte
basis, I'm not writing assembly.
x86
On Friday, 9 February 2018 at 11:16:01 UTC, Nick Sabalausky
(Abscissa) wrote:
/**
Be sure to check the various files at extras/foo*/package.d
and also: https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
*/
Unlike the "disabling code that contains the
end-of-disabled-code token" stuff, THIS
On Wednesday, 7 February 2018 at 12:10:38 UTC, dekevin wrote:
struct ℚ{
ℤ num, den; //cannot call constructors on these, since
they require gmp_init, which requires runtime code
//Default initialiser disabled, since else num=0,den=0
You can use a different default initializer:
On Wednesday, 7 February 2018 at 01:06:42 UTC, Luís Marques wrote:
On Wednesday, 7 February 2018 at 00:24:26 UTC, H. S. Teoh wrote:
I really like your .nx idea! It neatly sidesteps the
nonsensical mandatory casts and on top of that documents
intent (the .nx being a telltale sign of truncation
On Tuesday, 6 February 2018 at 07:15:33 UTC, Walter Bright wrote:
The thing is, when there are mixed integer sizes and
signedness, there is no intuitive and correct solution. Each
set of rules comes with its own set of cases where there are
unintuitive behaviors.
So, why doing any promotion
On Tuesday, 30 January 2018 at 11:44:11 UTC, Dominikus Dittes
Scherkl wrote:
I think they update only stuff for which security problems were
fixed and everything that depends on those, and that's it.
And by the way, for some people that is the reason to install
such a kind of distro:
to not
On Tuesday, 30 January 2018 at 09:38:26 UTC, aberba wrote:
On Monday, 29 January 2018 at 07:40:10 UTC, Dominikus Dittes
Scherkl wrote:
On Saturday, 27 January 2018 at 21:42:49 UTC, aberba wrote:
[...] Ubuntu 16.04
This is a long-term support distribution.
Don't expect those to have actual tip
On Saturday, 27 January 2018 at 21:42:49 UTC, aberba wrote:
[...] Ubuntu 16.04
This is a long-term support distribution.
Don't expect those to have actual tip versions of any SW package!
They rely on stabe versions that don't have the latest features
but only those very well tested.
On Thursday, 18 January 2018 at 06:05:08 UTC, rumbu wrote:
On Thursday, 18 January 2018 at 02:30:17 UTC, Rubn wrote:
On Wednesday, 17 January 2018 at 22:30:11 UTC, rumbu wrote:
code like "m = n < 0 ? -n : n" doesn't worth a wrapper
That code is worth a wrapper, it's called "abs"...
m =
On Monday, 15 January 2018 at 15:08:24 UTC, Kagamin wrote:
columnWidth as it only makes sense for column-oriented text
display.
I think displayWidth is better, because "width" is directly
linked to hozizontal direction (else it would be called hight),
and setting text in colums would still
On Thursday, 21 September 2017 at 13:58:14 UTC, Timon Gehr wrote:
On 21.09.2017 12:33, Per Nordlöw wrote:
On Wednesday, 20 September 2017 at 18:41:51 UTC, Timon Gehr
wrote:
Can that be done without breakages? -- Andrei
No.
Are thinking about
typeof([1,2])
changing from
int[]
On Tuesday, 15 August 2017 at 14:24:57 UTC, Steven Schveighoffer
wrote:
What IFTI would need is a mechanism to change the parameter
types to mutable similar to how you can do this:
foo(T)(const(T) t);
This now generates one function for int, const(int),
immutable(int), and t is const
On Monday, 14 August 2017 at 17:43:44 UTC, Dominikus Dittes
Scherkl wrote:
On Monday, 14 August 2017 at 15:20:28 UTC, Steven Schveighoffer
wrote:
What you can do, is:
auto foo(T)(T n) if (is(T == Unqual!T))
{
// normal implementation
}
auto foo(T)(T n) if (!is(T == Unqual!T) &&
On Monday, 14 August 2017 at 15:20:28 UTC, Steven Schveighoffer
wrote:
On 8/14/17 9:48 AM, Dominikus Dittes Scherkl wrote:
> uint foo(T)(Unqual!T n) // first try
> {
> ++n; // modify should be possible
> return 42;
> }
> Any ideas what I need to do to make this work?
This isn't exactly
if I use fixed-type functions, I can do the following:
uint foo(uint n)
{
++n; // modify n - as this function has received a copy of n,
this is always possible
return 42;
}
uint bar(const uint n)
{
assert(foo(n)==42);
return 17;
}
void main()
{
bar(3);
}
But if I try the
On Friday, 11 August 2017 at 09:27:47 UTC, Stefan Koch wrote:
On Tuesday, 1 August 2017 at 21:27:32 UTC, Stefan Koch wrote:
[ ... ]
Hey guys,
I just finished &&.
Hooray!
So what's still missing? Or is this now complete enough to
release?
On Friday, 11 August 2017 at 10:45:03 UTC, Mike Parker wrote:
The first stage of the formal review for DIP 1011 [1],
"extern(delegate)", is now underway.
I see no problem with this DIP.
And even if the usecase is rare, I think it is worth the new
syntax (and thereby increased complexity of
On Friday, 21 July 2017 at 13:51:05 UTC, Mike Parker wrote:
DIP 1009 is titled "Improve Contract Usability".
I like it.
I would prefer the out with two sets of parantheses.
On Wednesday, 19 July 2017 at 22:35:43 UTC, Jonathan M Davis
wrote:
The issue isn't the object being destroyed. It's what it refers
to via its member variables. For instance, what if an object
were to remove itself from a shared list when it's destroyed
(e.g. because it's an observer in the
On Wednesday, 19 July 2017 at 16:49:38 UTC, Jonathan Marler wrote:
This would automatically make it work with any statement:
with(auto x = 0) if(x)
{
doSomething
}
with(auto x = 0) while(x)
{
doSomething
}
Could also do multiple with statements
with(auto x = 0)
with(auto y = 0)
On Wednesday, 19 July 2017 at 16:13:28 UTC, Swoorup Joshi wrote:
On Wednesday, 19 July 2017 at 15:31:08 UTC, ag0aep6g wrote:
On 07/19/2017 03:30 PM, sontung wrote:
So I was thinking of some sort of syntax like this:
if(int i = someFunc(); i >= 0)
{
// use i
}
Thoughts
On Friday, 14 July 2017 at 10:43:05 UTC, Mike Parker wrote:
DIP 1011 is titled "extern(delegate)".
Looks good to me, useful, doesn't brake code, DIP seems correct.
On Wednesday, 12 July 2017 at 09:38:13 UTC, Martin Tschierschke
wrote:
On Monday, 10 July 2017 at 23:01:50 UTC, Luís Marques wrote:
On Monday, 10 July 2017 at 22:39:22 UTC, Petar Kirov
[ZombineDev] wrote:
The problem Walter pointed to is that due to integer
Ah, that makes sense. Thanks for
On Wednesday, 7 June 2017 at 21:18:21 UTC, ketmar wrote:
Ozan wrote:
On Wednesday, 7 June 2017 at 09:44:55 UTC, Ali Çehreli wrote:
Is there an issue with the tests? Surprised that vibe.d is
not higher in the rating...
https://www.techempower.com/benchmarks/#section=data-r14=ph=fortune
On Friday, 19 May 2017 at 21:25:22 UTC, Stefan Koch wrote:
On Friday, 19 May 2017 at 21:23:11 UTC, Dominikus Dittes
Scherkl wrote:
And it's not visible from the API or documentation - you need
to look into the source to disambiguate - I'm not convinced
and still consider this bad style.
If
On Friday, 19 May 2017 at 22:06:59 UTC, Moritz Maxeiner wrote:
On Friday, 19 May 2017 at 20:54:40 UTC, Dominikus Dittes
Scherkl wrote:
I take this to mean the programmer who wrote the library, not
every user of the library.
I take this to mean any programmer that ends up compiling it
(if
On Friday, 19 May 2017 at 21:04:24 UTC, Stefan Koch wrote:
If a template does trigger a static assert,
that static assert is ignored if there is another template in
the overload set that could match.
Wow. Didn't know that.
Is this really part of the D grammar?
Sometimes D is soo cool.
Still
On Friday, 19 May 2017 at 20:19:46 UTC, Moritz Maxeiner wrote:
On Friday, 19 May 2017 at 17:21:23 UTC, Dominikus Dittes
Scherkl wrote:
You cannot promise to the compiler that the code is memory
safe since you have no knowledge of what it actually does.
No. @trusted is about trust: you cannot
On Friday, 19 May 2017 at 17:47:42 UTC, Stefan Koch wrote:
On Friday, 19 May 2017 at 17:34:28 UTC, Dominikus Dittes
Scherkl wrote:
On Friday, 19 May 2017 at 00:14:05 UTC, Stefan Koch wrote:
string enumToString(E)(E v)
{
static assert(is(E == enum),
"emumToString is only meant for
On Friday, 19 May 2017 at 00:14:05 UTC, Stefan Koch wrote:
string enumToString(E)(E v)
{
static assert(is(E == enum),
"emumToString is only meant for enums");
Why that assert? We can check it at compiletime. Doesn't this cry
for a constraint? I would use asserts only ever for
On Friday, 19 May 2017 at 15:52:52 UTC, Moritz Maxeiner wrote:
On Friday, 19 May 2017 at 15:12:20 UTC, Steven Schveighoffer
I don't expect people to use Phobos and audit all the @trusted
blocks personally.
As long as they don't actually call them, that's reasonable.
But if your application
On Wednesday, 17 May 2017 at 20:25:26 UTC, Stefan Koch wrote:
On Wednesday, 17 May 2017 at 19:26:32 UTC, tsbockman wrote:
On Wednesday, 17 May 2017 at 15:30:29 UTC, Stefan Koch wrote:
the special case it supports if cast(uint*)
and cast(ulong*)
What about casting from real* when real.sizeof
On Monday, 15 May 2017 at 06:03:27 UTC, Mike Parker wrote:
There's a PR for a new DIP titled "Delegatable Functions" [1].
If you have time, I invite you to review the PR to make sure
it's in the best state possible for moving forward to a merge
and preliminary review. At this stage, we're
On Thursday, 11 May 2017 at 10:07:32 UTC, Joakim wrote:
On Thursday, 11 May 2017 at 02:05:11 UTC, Nikolay wrote:
I am porting LDC to NetBSD amd64, and I ask advice how to
handle real type. NetBSD has limited support for this type.
What is long double on NetBSD/amd64, 64-bit or full 80-bit?
On Friday, 28 April 2017 at 13:19:47 UTC, Chris wrote:
On Thursday, 27 April 2017 at 12:29:48 UTC, Steven
Schveighoffer wrote:
On 4/24/17 1:43 AM, Nick Sabalausky (Abscissa) wrote:
"Dashing, awesome, ultra-attractive programmer with an
impeccably fine
taste in languages."
It's a bit long
On Monday, 24 April 2017 at 15:03:53 UTC, Mike Parker wrote:
DIP 1007 is titled "'future symbol' Compiler Concept".
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md
+1
I like the idea of beeing warned about new symbols in libraries,
so that I can change my symbols ahead.
On Friday, 21 April 2017 at 17:20:14 UTC, Vasudev Ram wrote:
Hi list,
I hope the question is self-evident from the message subject.
If not, it means: what are D developers generally called (to
indicate that they develop in D)? The question occurred to me
somehow while browsing some D posts
On Tuesday, 7 March 2017 at 02:51:37 UTC, Jonathan M Davis wrote:
If we can, we should probably make structs that have opCmp use
opCmp like they should, and those that don't continue to use
memcmp for the moment but get a deprecation message. Then after
whatever amount of time we think is
On Monday, 20 February 2017 at 21:05:17 UTC, Jack Stouffer wrote:
On Monday, 20 February 2017 at 20:54:31 UTC, Jack Stouffer
wrote:
On Monday, 20 February 2017 at 20:49:43 UTC, Johan Engelen
wrote:
...
Yeah, this is another regression caused by DIP1000.
Christ.
For the record, the current
On Tuesday, 14 February 2017 at 20:46:17 UTC, Walter Bright wrote:
Range remove
[...]
But there's another issue here. remove() has other overloads:
[...]
Two constraints are common to all three, those are the only
ones that actually need to be in the constraint. The others can
go in the
On Monday, 13 February 2017 at 14:28:20 UTC, Mike Parker wrote:
Daniel Nielsen put together a post describing the import idiom
that came to light in a recent forum discussion regarding DIP
1005 [3]. The relevant links are at [1] and [2].
[1]
On Friday, 10 February 2017 at 17:15:12 UTC, Dominikus Dittes
Scherkl wrote:
Hmm. For me seems like you got some comments on your PR but
didn't answer. Seems plausible not to include such PR.
Ah, you received those answers just now, not at that time.
Sorry.
On Friday, 10 February 2017 at 14:36:31 UTC, Nemanja Boric wrote:
On Friday, 10 February 2017 at 02:42:10 UTC, Andrei
Alexandrescu wrote:
On 02/09/2017 05:03 PM, Daniel Kozak wrote:
Is this still accurate? I mean if I change some issue to
"trivial", is
there any process which will notify you
On Friday, 10 February 2017 at 13:28:43 UTC, Dominikus Dittes
Scherkl wrote:
Sorry, accidentally hit some key-combination that immediately
send the message that was not yet complete.
With my original proposal you would write
auto foo(foo.SysTime st1,
foo.SysTime st2,
On Thursday, 9 February 2017 at 05:40:01 UTC, Jonathan M Davis
wrote:
On Friday, February 03, 2017 14:43:01 Dominikus Dittes Scherkl
via Digitalmars-d wrote:
Any thoughts?
This is really cool, but I have a couple of concerns about this
and how it seems deficient in comparison to DIP 1005
On Monday, 6 February 2017 at 09:00:43 UTC, Mike Parker wrote:
On Monday, 6 February 2017 at 08:45:45 UTC, Dominikus Dittes
Scherkl wrote:
But is this really worth an article?
IMO, as something targeted at non-D users, yes.
Oh yeah? For bragging about how D uses modules and doesn't need
On Monday, 6 February 2017 at 06:08:22 UTC, Chris Wright wrote:
On Sat, 04 Feb 2017 23:48:48 -0800, Ali Çehreli wrote:
What I and many others who say Errors should not be caught are
saying is, once the program is in an unexpected state,
attempting to do anything further is wishful thinking.
On Friday, 3 February 2017 at 23:33:58 UTC, Walter Bright wrote:
On 2/3/2017 11:14 AM, Andrei Alexandrescu wrote:
On 2/3/17 10:41 AM, Daniel N wrote:
On Friday, 3 February 2017 at 14:43:01 UTC, Dominikus Dittes
Scherkl wrote:
DIP 1005 provides new syntax to make it possible to avoid
global
On Friday, 3 February 2017 at 14:59:09 UTC, rikki cattermole
wrote:
On 04/02/2017 3:43 AM, Dominikus Dittes Scherkl wrote:
DIP 1005 provides new syntax to make it possible to avoid
global imports.
But this can already be worked around with some nice trick:
Any thoughts?
Needless syntax
DIP 1005 provides new syntax to make it possible to avoid global
imports.
Till now global imports are necessary if a function uses types
declared in some imported module within it's declaration or
definition (otherwise a local import will do).
But this can already be worked around with some
On Friday, 3 February 2017 at 09:28:26 UTC, yazd wrote:
Is it possible to have non-@safe callbacks be part of the
non-deprecated API?
Why?
A @safe API allows you to use it within @safe code, but it
doesn't require you to also write @safe code.
Especially if you don't like to annotate your code
On Saturday, 21 January 2017 at 15:55:35 UTC, Xavier Bigand wrote:
I don't see any other use case than for initialized maths
struct to an invalid state, and because it is generally in
template that working with integers and floats it is easier to
have same properties (when it have the same
On Thursday, 19 January 2017 at 14:29:46 UTC, Jack Stouffer wrote:
From what I understand, the difference between an Exception and
and Error is that Errors signal your program has entered into
an invalid state. For example, going past the end of an array
and attempting to access that memory.
On Tuesday, 3 January 2017 at 12:57:22 UTC, Andrei Alexandrescu
wrote:
On 01/03/2017 02:19 AM, Dominikus Dittes Scherkl wrote:
On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu
wrote:
DIP1005 gives consideration to the speed of compilation
aspect in
larger proportion than speed's
On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu
wrote:
DIP1005 gives consideration to the speed of compilation aspect
in larger proportion than speed's importance; the first and
foremost benefit of DIP1005 is it closes the gap on dependency
encapsulation, which had been very
On Friday, 16 December 2016 at 07:15:51 UTC, Walter Bright wrote:
On 12/15/2016 9:07 AM, Dominikus Dittes Scherkl wrote:
So, I no longer propose to change nothing except the internal
compiler behaviour.
Now I propose to additionally change the .di-file generation
to also add all
local imports
On Thursday, 15 December 2016 at 16:16:51 UTC, Walter Bright
wrote:
On 12/14/2016 5:26 AM, Dominikus Dittes Scherkl wrote:
Why not leave it as it is and only change the compiler to
perform inputs _within_ a function before evaluating the
declaration, so that
the symbols imported can be used
On Wednesday, 14 December 2016 at 12:33:04 UTC, Tanel L wrote:
Any ideas what to do or how to proceed?
Thanks a bunch!
This kind of questions is better adressed to the "Learn" forum.
1 - 100 of 252 matches
Mail list logo
