On Monday, 29 July 2019 at 05:58:21 UTC, dmm wrote:
So, d try to be smart, only make thing worse?
D is behaving exactly as it should here. You simply have a wrong
model of what an array is in D.
In C++, an array owns its memory. In D, an array is a thin
wrapper around GC managed memory. As
On Wednesday, 19 June 2019 at 04:00:44 UTC, Norm wrote:
Is the JSON_TYPE deprecation listed in the changelog, I
couldn't see it? I was on 2.086.0 prior to trying this beta
which did not show the deprecation.
Cheers,
Norm
That was back on 2.082.0, to make it match the D style guide. Not
On Sunday, 12 May 2019 at 05:43:01 UTC, Walter Bright wrote:
All this effort strongly implies that there's no such thing as
a satisfactory bool type. Will you succeed where 10,000 other
programmers have failed? Seems unlikely. But I doubt I will
dissuade you from trying.
If you succeed at
On Sunday, 7 April 2019 at 03:47:25 UTC, Alex wrote:
rules are meant to be broken.
No they're not! Almost by definition not!
More comprehensively, if you break a rule you take responsibility
for the outcome. You wanna use stringof? "Don't use stringof for
that." "rules are meant to be
https://gist.github.com/FeepingCreature/6c67479c99bc0f20544d1e455622ae82
Usage: DMD= progress-dmd
The script sets -v and then uses the code and semantic stages
logged in the output to paint a cute little ANSI-colored progress
bar, with one character for every file listed on the command line.
On Monday, 28 January 2019 at 15:16:54 UTC, Steven Schveighoffer
wrote:
It will inspect the allocated length from the GC if the array
is appendable from the beginning. So it's not always going to
reallocate.
e.g.:
string x = "abc".idup;
auto app = x.appender;
app ~= "xyz"; // does not
On Friday, 25 January 2019 at 14:33:16 UTC, Steven Schveighoffer
wrote:
On 1/25/19 3:20 AM, FeepingCreature wrote:
On Thursday, 24 January 2019 at 17:49:34 UTC, Ali Çehreli
wrote:
Aren't the semantics of .clear that it's invalid to access
references to .data after calling .clear, period? And
On Thursday, 24 January 2019 at 17:49:34 UTC, Ali Çehreli wrote:
On 01/24/2019 04:35 AM, FeepingCreature wrote:
> On Tuesday, 27 March 2018 at 12:31:05 UTC, Simen Kjærås wrote:
>> On Tuesday, 27 March 2018 at 12:17:58 UTC, Ellie Harper
wrote:
>>> Sorry if this is a stupid question, but is there
On Tuesday, 27 March 2018 at 12:31:05 UTC, Simen Kjærås wrote:
On Tuesday, 27 March 2018 at 12:17:58 UTC, Ellie Harper wrote:
Sorry if this is a stupid question, but is there something
special required to call Appender.clear? When I attempt even
just a simple use I am getting compile errors
Typo: to not* be a warning
On Wednesday, 26 September 2018 at 16:29:24 UTC, Neia Neutuladh
wrote:
* If you encounter a mixin in the module you're analyzing, give
up.
Unfortunately, our code uses mixins heavily, so I don't think
this would be useful for us.
In any case, I fundamentally don't consider the approach of
On Wednesday, 26 September 2018 at 08:37:12 UTC, Dejan Lekic
wrote:
I humbly believe this does not belong to the compiler. These
sort of things belong to a static code analyser TOOL. Think of
checkstyle/findbugs in Java, or flake8/pep8 in Python world.
I can't put it differently than this:
On Wednesday, 26 September 2018 at 01:13:11 UTC, Jonathan M Davis
wrote:
IMHO, the only time that anything along the lines of a warning
makes sense is when the programmer is proactively running a
tool to specifically ask to be informed of a potential type of
problem where they will then go
On Tuesday, 25 September 2018 at 19:28:47 UTC, Jacob Carlborg
wrote:
The DMD compiler is available as a library. A linter tool can
be based on that.
Repeating it here: the library does not have version-tagged
releases. For a build system based around reproducible builds,
this makes it
On Tuesday, 25 September 2018 at 14:28:48 UTC, FeepingCreature
wrote:
Maybe stick the info in -v or -deps?
Actually, -deps is the perfect place for it. It needs to
recursively evaluate modules anyways, so it'll see an import even
if it was only used from a template. And it doesn't spam up
On Tuesday, 25 September 2018 at 14:15:32 UTC, Dominikus Dittes
Scherkl wrote:
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:
On Tuesday, 25 September 2018 at 13:14:36 UTC, Jonathan M Davis
wrote:
If something is definitively wrong, then it should be an error.
If it's not definitively wrong, then the compiler shouldn't say
anything about it, and it should be left up to a linter tool of
some kind like dcd.
-
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:
[...]
For instance, I've been thinking about hiding the warning behind
an additional flag (-wunused-imports or -wu?) so that it's
opt-in. Would that be
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)() { writeln("Hello World"); }
foo.d: Warning: unused import
To be fair,
On Friday, 21 September 2018 at 23:17:42 UTC, Seb wrote:
In all seriousness I hate it when someone thought its funny to
use the lambda symbol as an identifier and I have to copy that
symbol whenever I want to use it because there's no convenient
way to type it.
(This is already supported in
On Monday, 27 August 2018 at 11:02:14 UTC, Guillaume Piolat wrote:
C++ binds the two in the same operation.
D does not, T.init must be a valid object. This is a major
cultural change, though I believe the D way is superior on the
efficiency stand-point (you can create large arrays of valid
- Consider a short form for "dispatch". Purely for convenience:
e.g.: john.d.residence.d.numberOfRooms;
Why not .get, like Nullable?
As long as you never alias it to this... ;)
On Sunday, 26 August 2018 at 22:44:05 UTC, Walter Bright wrote:
On 8/26/2018 8:43 AM, Chris wrote:
I wanted to get rid of autodecode and I even offered to test
it on my string heavy code to see what breaks (and maybe write
guidelines for the transition), but somehow the whole idea of
getting
On Friday, 24 August 2018 at 01:57:03 UTC, Shachar Shemesh wrote:
That's strange. Why didn't Shachar just do?
_trustedData[diskIdx] &= NotBitmap(toDistrust);
Answer: Because the compiler decided that it needs to call
_trustedData.opIndexAssign, and then failed the compilation
because
On Monday, 23 July 2018 at 14:26:17 UTC, Nick Treleaven wrote:
On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature
wrote:
To reproduce the format issue, try to print the struct with
writefln!"%s"(MyDomainType()).
I implemented the compile time format string checking by
evaluating
Update:
https://github.com/dlang/dmd/pull/5830
Turns out unions with fields with destructors is **define
behavior**. I did not know this. Probably the spec needs updating.
So that pretty much alleviates the need for this DIP. Though I
kind of half-believe that this DIP is actually *better*
On Friday, 27 July 2018 at 11:44:10 UTC, aliak wrote:
A) I'd suggest "@nodestruct" instead, since it sounds like that
what it's supposed to do?
Yes-ish, but it's also supposed to fill the hole in the
typesystem created by T.init, and "you can only assign T.init to
types marked @nodestruct"
A new UDA is introduced: @manualScoped. It is valid for fields in
structs and classes, as well as variables and parameters. Fields
marked with @manualScoped are not automatically destructed on
scope end.
For instance, a function taking a struct as a @manualScoped value
will lead to a copy
On Wednesday, 25 July 2018 at 09:13:27 UTC, Mike Franklin wrote:
On Wednesday, 25 July 2018 at 08:27:25 UTC, Rel wrote:
To be exact as a "HEUR:Trojan-Downloader.Win32.Agent.gen".
Few other AV software does the same:
On Thursday, 12 July 2018 at 08:54:17 UTC, Simen Kjærås wrote:
Whether that means it's undefined behavior or the compiler
should statically disallow it is up for debate, I guess.
--
Simen
Honestly, half the reason I'm using it so enthusiastically is
that I want to emphasize that this is
On Wednesday, 11 July 2018 at 20:10:17 UTC, Meta wrote:
I hate to say I told you so, but...
https://github.com/dlang/phobos/pull/5855#issuecomment-345783238
Just joking, of course =)
Nullable has needed to be completely overhauled for a long time
because it was only really designed with POD
Oh yeah, two notes.
First: you might say "it's easy to be un@safe if you use
@trusted." However, the @trusted part is both well-defined and
positively pedestrian, since we are either targeting default
initialized memory or just ran destroy() on it (which by the way
is @safe) so really, if
// So I was working on Nullable,
// and I thought: how could this be made to work better?
// The following code runs on DMD master,
// and it is, technically, `safe`;
// but it REALLY REALLY shouldn't be.
module turducken;
import std.algorithm;
import std.datetime;
// The Turducken Type
Destructors are not called for fields embedded in unions.
On the one hand this is a horrible, horrible hack. On the other,
whee!
On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature wrote:
Then just stick it in a Nullable. No explicit .init needed.
To clarify this point some more, since on reflection it's
ambiguous: you might well say that "well yeah, the default
constructor returns an invalid value, no shit it
On Tuesday, 10 July 2018 at 21:08:32 UTC, Cym13 wrote:
First of all I must point that I would very much like to have
seen a code actually producing an error in that article.
Contrary to what is hinted just taking the struct and putting
using it with Nullable or format() caused no error for me
On Tuesday, 10 July 2018 at 13:38:33 UTC, Jonathan M Davis wrote:
He thought that it was critical that the invariant be valid
when opAssign was called - and there are cases where that's
arguably true - but since it doesn't work once you try to do
fancier stuff like emplace, I'm of the opinion
I've written up a short blogpost about the T.init issue.
It is not very enthusiastic.
https://medium.com/@feepingcreature/d-structs-dont-work-for-domain-data-c09332349f43
Related links:
https://github.com/dlang/phobos/pull/6594 problem with T.init and
toString
On Tuesday, 10 July 2018 at 00:01:28 UTC, Steven Schveighoffer
wrote:
On 7/7/18 11:06 PM, FeepingCreature wrote:
On Friday, 6 July 2018 at 23:37:30 UTC, Simen Kjærås wrote:
As for alignment, GC, and possibly other things, the code was
not intended as a complete implementation of Nullable, only
On Friday, 6 July 2018 at 23:37:30 UTC, Simen Kjærås wrote:
As for alignment, GC, and possibly other things, the code was
not intended as a complete implementation of Nullable, only to
show that an actual member of type T is not necessary. These
issues are fixable, if perhaps nontrivial in
On Friday, 6 July 2018 at 12:10:58 UTC, Simen Kjærås wrote:
The rest looks sensible to me, but I have to say this is
bollocks. This Nullable never has to construct an S.init:
struct Nullable(T) {
ubyte[T.sizeof] _payload;
bool _hasValue;
Come on, at least make it a union with a
On Friday, 6 July 2018 at 10:44:09 UTC, FeepingCreature wrote:
Consider the humble struct S
{
Object obj;
invariant
{
assert(this.obj !is null);
}
@disable this();
this(Object obj)
in(obj !is null)
{
this.obj = obj;
}
}
Oops - there should of
I believe there's a good case that struct invariants should not
be called on struct destruction. Significantly, I believe that
Phobos, in particular `moveEmplace`, is already written as if
this is the case, even though it is not specified anywhere.
It is very common for structs' .init to
On Wednesday, 4 July 2018 at 10:47:12 UTC, Jonathan M Davis wrote:
At this point, to operate on anything that's shared, either
means using atomics or protecting the data with a mutex (be
that with a synchronized block / function or a mutex object)
and temporarily casting away shared while
On Saturday, 23 June 2018 at 04:45:07 UTC, user1234 wrote:
There is this case that requires parens:
if a && b c;
Is there a missing && or not ? It seems obvious for a human but
compiler parsers are "apparatchiks", i.e rules are rules. That
being said this would work by allowing parens
On Friday, 29 June 2018 at 07:31:42 UTC, Eugene Wissner wrote:
You can move only exactly the same type. with opAssign you can
assign a differnt type. So opAssign should forward assignment
to the underlying type if you assign nor Nullable!T nor T.
Sorry, that was unclear; I meant to ask for
I'm doing a pull request to rewrite Nullable to use
moveEmplace/move to replace its internal value. I'm considering
whether it's better to let Nullable destroy its existing value,
then memcpy the new one over it (via move()), or if it already
has a value in it, if an opAssign to Nullable
On Wednesday, 27 June 2018 at 12:49:20 UTC, FeepingCreature wrote:
Maybe it's finally time to write an emplace-based version of
Nullable?
Having done so: is it better to have just the moveEmplace
Nullable, or use standard opAssign for implicitly constructable
types? This would let Nullable
Augh, nevermind, it's immutable TimeZone. TimeZone needs to be
immutable for some reason, so it needs Rebindable, so SysTime has
opAssign anyways, because there's no native way to specify a
tailconst for class references.
Augh.
Maybe it's finally time to write an emplace-based version of
The overloaded opAssign in SysTime makes it unusable with
Nullable in structs that have invariants that fail on T.init and
hence @disable this().
struct S
{
SysTime st_;
int i;
invariant { assert(i > 0); }
this(int i) { this.i = i; }
@disable this(); // S() is not a valid S
}
Can somebody explain what tnext does in TemplateInstance? It
seems to be at the root of this stack overflow. The comment says
it's "non-first instantiated instances", which is somewhat less
than helpful.
On Tuesday, 5 June 2018 at 17:47:15 UTC, Steven Schveighoffer
wrote:
Another observation: under the "infinite loops are important
observable behavior" world-view, pure functions cannot be
lazily evaluated either:
pure int foo() { /*infinite loop */}
void main(string[] args)
{
auto a =
I'm just posting to clear up the misunderstanding that a call to
a pure function can be removed. Actually, even calls to strongly
pure functions cannot always be removed. This is because there is
one thing that a pure function can do that will change program
behavior if it is removed, even if
On Wednesday, 30 May 2018 at 10:05:42 UTC, H. S. Teoh wrote:
What about this?
--
struct EndOfArgs { }
EndOfArgs eoa;
void func(string s, EndOfArgs _ = eoa,
string file = __FILE__, size_t line = __LINE__)
{
import std.stdio;
writefln("%s:%d: msg=%s", file, line, s);
On Wednesday, 30 May 2018 at 11:59:05 UTC, bauss wrote:
On Wednesday, 30 May 2018 at 08:27:16 UTC, FeepingCreature
wrote:
There's a very common idiom where in order to report line
numbers of an error or a log line at the callsite of a
function, you pass __FILE__ and __LINE__ as default
On Wednesday, 30 May 2018 at 08:27:16 UTC, FeepingCreature wrote:
struct CallerInfo
{
string file;
size_t line;
}
Let me try to flesh this out.
void foo(CallContext caller = __CALL_CONTEXT__)
{
}
// in druntime object.d
struct CallContext
{
public size_t line; // expected to change for
Updated subject to be visible at a glance.
Note that a compiler-based solution via __CALLER__ would still
work.
Shit it doesn't work, I only checked if it compiled; it gives the
wrong file/line number.
NEVERMIND ALL
There's a very common idiom where in order to report line numbers
of an error or a log line at the callsite of a function, you pass
__FILE__ and __LINE__ as default parameters:
void foo(string file = __FILE__, size_t line = __LINE__);
What's wrong with this?
Say you add a string parameter,
I've hit a bit of a snag while implementing the PR.
https://issues.dlang.org/show_bug.cgi?id=18775 seems to make
deprecating the implicit conversion basically impossible, because
the deprecation will be triggered on every UFCS access to a
Nullable, no matter whether it actually uses .get or
On Wednesday, 18 April 2018 at 10:01:17 UTC, Nick Treleaven wrote:
On Wednesday, 18 April 2018 at 08:24:14 UTC, FeepingCreature
wrote:
If nobody objects, I'll make a PR to deprecate it.
+1. Nullable has received some improvements lately, it would be
great if `get` was no longer implicit. For
If nobody objects, I'll make a PR to deprecate it.
Addendum: The general principle is that a "narrowing conversion"
should never be implicit. An example of a narrowing conversion is
float to int, or int to short. In the case of integer types, D
already follows this rule.
Nullable!T to T is a narrowing conversion, since T cannot express
the
Say that we have a function that returns an int. We assign it to
an auto variable and pass that to another function which takes an
int. All is well.
Say we change the function to return a Nullable!int. We expect
the compiler to warn us that we must now check for isNull;
however, what we
I think `alias get this` is a misfeature.
If at all possible, compiletime errors should be preferred over
runtime errors. The point of Nullable is that the value contained
within may be absent. Considering the prevalence of type
inference and UFCS chaining in idiomatic D, it is very possible
Hi, can somebody please review
https://github.com/dlang/phobos/pull/6366 ? Phobos currently
calls localtime() to handle timezones, which breaks insidiously
in multithreaded programs and occasionally silently returns wrong
times. localtime_r() support is not 100% universal, but
localtime() is
For what it's worth, I like autodecoding.
I worry we could be in a situation where a moderate number of
people are strong opponents and a lot of people are weak fans,
none of which individually care enough to post. Hopefully the D
survey results will shed some light on this, though I don't
101 - 167 of 167 matches
Mail list logo
