n
body, it really shouldn't matter which you use.
- Jonathan M Davis
time,
because the arguments to foreach are not compile-time arguments.
In contrast,
foreach(i; AliasSeq!(1, 2, 3, 4, 5))
{...}
static foreach(i; AliasSeq!(1, 2, 3, 4, 5))
{{...}}
would both run at compile time, because AliasSeq is a compile-time
construct and must be evaluated at compile time.
- Jonathan M Davis
normally generate automatically, giving you the
ability to do things like make a struct uncopyable or unassignable.
- Jonathan M Davis
s sense, but you'll be fighting the language pretty much
any time that you try it. As general rule, it really only makes sense in
very restricted circumstances, and even then, it's better to use a factory
function with an actual name.
- Jonathan M Davis
bly should add an appropriate template
helper to Phobos to be used instead.
So, the TLDR is that variables should only ever be default-iniatialized by
simply declaring them - and that structs should never be constructed with no
arguments whether it's to default-iniatialize them or if it's to use a
factory functions. Factory functions should just get their own names.
- Jonathan M Davis
ated carefully, so I wouldn't be
passing it around, and it wouldn't be part the API, so I wouldn't normally
have any instances of it floating around to even be referred to as objects.
Regardless, it's not like we have a precise definition of what "object"
means in D in the spec anywhere AFAIK. And the way that folks use it is
probably strongly colored by their experience with other languages.
- Jonathan M Davis
ing, then you're going to tend to get a
lot of comparing and contrasting between languages, sometimes with someone
trying to claim that a particular language doesn't really qualify, because
it doesn't fit how they use the term (which was probably strongly influenced
by whichever languages they've used the most).
- Jonathan M Davis
)
{
int[] temp;
temp ~= foo();
temp ~= bar();
i = cast(immutable) temp; // @system
}
if you wanted operate on a fully mutable array, but the type system is
supposed to guarantee that immutable data is never mutated, so the compiler
does not allow you to mutate an immutable variable even in a constructor.
It just allows you to initialize it.
- Jonathan M Davis
doesn't have to worry about whether T is a type where scope has any real
meaning.
So, in some respects, ignoring attributes that can't apply simplifies
things, but of course, there are also situations where it causes confusion.
And maybe the compiler should make more of those cases errors than it
currently does, but it would likely be worse overall to make them all
errors.
- Jonathan M Davis
if there's nothing
> available.
>
> tinytag is nice, because it handles wav/ogg/flac/opus/mp3
> uniformly.
If you're looking to operate on tags in audio files, then there's
https://code.dlang.org/packages/taglib-d, which might do what you need, but
I don't know much about it, so I can't say for sure.
- Jonathan M Davis
On Sunday, July 13, 2025 1:45:01 PM Mountain Daylight Time Ali Çehreli via
Digitalmars-d-learn wrote:
> On 7/12/25 5:35 PM, Jonathan M Davis wrote:
> > On Saturday, July 12, 2025 5:55:39 PM Mountain Daylight Time Ali
> Çehreli via Digitalmars-d-learn wrote:
> Anything can b
On Sunday, July 13, 2025 8:38:08 AM Mountain Daylight Time H. S. Teoh via
Digitalmars-d-learn wrote:
> On Sat, Jul 12, 2025 at 06:35:42PM -0600, Jonathan M Davis via
> Digitalmars-d-learn wrote:
> > On Saturday, July 12, 2025 5:55:39 PM Mountain Daylight Time Ali Çehreli
> >
On Sunday, July 13, 2025 5:00:12 AM Mountain Daylight Time Bienlein via
Digitalmars-d-learn wrote:
> On Sunday, 13 July 2025 at 00:35:42 UTC, Jonathan M Davis wrote:
>
> > Whereas I think that using private makes perfect sense when you
> > want something to be an implementatio
details which can be changed as necessary so long as those
changes don't break the functionality provided by the public symbols. So,
from the standpoint of code maintenance, there can be real value in keeping
symbols private.
- Jonathan M Davis
ritySend
https://dlang.org/phobos/std_concurrency.html#.receive
https://dlang.org/phobos/std_concurrency.html#.receiveOnly
https://dlang.org/phobos/std_concurrency.html#.receiveTimeout
- Jonathan M Davis
On Saturday, July 5, 2025 2:19:11 AM Mountain Daylight Time partypooper via
Digitalmars-d-learn wrote:
> On Saturday, 5 July 2025 at 08:08:08 UTC, Jonathan M Davis wrote:
> > On Friday, July 4, 2025 12:04:55 PM Mountain Daylight Time
> > partypooper via Digitalmar
So, hopefully it gets fixed at some point here, but for now, we're kind of
stuck, and you'll need unit tests to catch the cases where you accidentally
do some form of assignment on an rvalue when overloaded operators are
involved.
- Jonathan M Davis
On Friday, June 27, 2025 10:31:42 AM Mountain Daylight Time Quirin Schroll via
Digitalmars-d-learn wrote:
> On Tuesday, 24 June 2025 at 02:05:40 UTC, Jonathan M Davis wrote:
> > There's also the issue of templated code. If an attribute is
> > desirable in the cases where it
rearrange
the member variables in whatever the optimal order is. And in most cases,
personally, I don't care enough to bother figuring it out (though that's
also why I've considered writing something to at least tell me the optimal
order for space savings so that I can get an answer without having to think
about it).
- Jonathan M Davis
recation message if you don't provide a
toHash which will work with Nullable's toHash.
So, if you want correct behavior (and no deprecation message), then you'll
need to define an opEquals and toHash which do the correct thing for your
type, _and_ you'll need its toHash to be @safe, const, and nothrow to work
around the bug in Nullable's toHash. Once Nullable's toHash is fixed, the
attribute issue will go away though, and you should then be able to not have
those attributes on your toHash if you don't want to.
- Jonathan M Davis
sort of subtype.
What you've shown there with allowing a B to be passed as an A is called
object slicing, and avoiding that is one of the main reasons that structs
and classes were separated in D in the first place. It's a source of bugs in
C++.
- Jonathan M Davis
ems
from the current situation, and it's debatable as to which situation is
better or worse, but it's nowhere near as straightforward as it first seems.
- Jonathan M Davis
f the same operations as built-in types
with semantics which are consistent with those operators for built-in types.
There are cases where that could be done with overloaded operators defined
outside of the type if that were allowed, but changing how an operator works
for a built-in type definitely goes against what the ability to overload
operators is intended for.
- Jonathan M Davis
ou look at std.container, each container type follows this pattern. It
implements opSlice which then returns a range over the container.
You can then use the range over the container with range-based functions
such as chain.
- Jonathan M Davis
rticular is extremely controversial and likely will
not become the default in its current form. scope does have _some_ effect
without it, but it's minimal. However, with DIP 1000, scope becomes a
complicated mess. And even then, it's usually only useful if you're trying
to avoid the GC for some reason.
- Jonathan M Davis
template
instantiation is going to be unique, and that's going to mean a lot of
template bloat.
Once in a blue moon, you do need the file or line number to be a template
argument, but it's pretty much always better to make them function arguments
if you can.
- Jonathan M Davis
works, whereas in languages that don't allow
narrowing conversions, you typically have to cast, which of course can be
annoying. But that's the price of avoiding invisible truncation with
arithmetic. It's just that the fact that smaller integer types get converted
to int for arithmetic makes it worse, though if they weren't, you'd be
getting integer overflow with them pretty frequently, I expect.
- Jonathan M Davis
On Wednesday, May 14, 2025 5:38:59 AM Mountain Daylight Time Nick Treleaven via
Digitalmars-d-learn wrote:
> On Wednesday, 14 May 2025 at 03:36:40 UTC, Jonathan M Davis wrote:
> > to!string definitely deals with null-terminated strings, or it
> > wouldn't work at all. It
cing instead of allocating a copy.
But ultimately, whether you use to!string(ptr) or fromStringz(ptr).idup is
really a matter of personal preference - especially if you're not dealing
with generic code. I suspect that more folks would think that using
to!string(ptr) looked better, but I don't know. Personally, I'd probably use
fromStringz(ptr).idup just to make the operation explicit, but that's simply
my preference. Do whichever you prefer. They both work just fine.
- Jonathan M Davis
ng D's
main (which is probably C's main as generated by the compiler, though there
might be functions in between depending on the current implementation).
And FYI, the post that you responded to was from 2011. I'm guessing that you
found it via searching, but given its age, the folks who were in that thread
likely don't even remember that it exists.
- Jonathan M Davis
lgorithm.searching.find or std.algorithm.countUntil to get the
element's offset to pass to remove.
- Jonathan M Davis
er
at that point in the iteration. It's just that with an iterator, you get
something that points to that individual element, whereas with a range, you
get a range of values which starts with that element. But it's certainly
true that the range equivalents of iterator-based algorithms can take some
getting used to.
- Jonathan M Davis
, 1, 1, 1]
[2, 2, 2, 2, 1, 1, 1, 1]
core.exception.RangeError@q.d(13): Range violation
??:? onRangeError [0x29f6b6]
??:? _d_arrayboundsp [0x29f685]
??:? _Dmain [0x27c099]
- Jonathan M Davis
value. A function
pointer could be, but a function cannot be - and neither can a lambda,
because a lambda is an anonymous function, not a function pointer.
Basically, if it doesn't make sense for something to be assigned to a
variable, then it doesn't make sense for it to be an enum.
- Jonathan M Davis
difference between a pointer and a reference. They just point to an object.
It's escaping which is potentially a problem (which ref is stricter about)
and pointer arithmetic (which can't be done with ref). Basically, as long as
what you're doing with a pointer is what can be done with a reference, then
it's @safe.
- Jonathan M Davis
On Wednesday, April 9, 2025 1:11:35 AM MDT Anonymouse via Digitalmars-d-learn
wrote:
> On Tuesday, 8 April 2025 at 14:27:24 UTC, Jonathan M Davis wrote:
> > I would assume that you need to create a similar build config
> > which doesn't use -w (though really, -w should
On Tuesday, April 8, 2025 9:07:45 AM MDT Guillaume Piolat via
Digitalmars-d-learn wrote:
> On Tuesday, 8 April 2025 at 14:00:56 UTC, Jonathan M Davis wrote:
> > Of course, I'm also increasingly of the opinion that pure was a
> > mistake in general, because it does almost
for my needs. ddoc is great once you put some effort
into getting it set up, but before that, the experience isn't great - though
it may be good enough depending on what you're trying to do, and the dub
docs build configuration may make it more pleasant if you can get it
working.
- Jonathan M Davis
to the compiler and get it wrong, you can get issues that
will be pretty hard to catch or debug, whereas if you just don't bother with
pure, you avoid all of the associated problems without actually losing
anything in almost all cases.
- Jonathan M Davis
nly
container from Phobos that I've actually used in any of my code, since
occasonally, you need a sorted map or set, and dynamic arrays and AAs don't
work well for that, but RedBlackTree does.
- Jonathan M Davis
r is just giving the same error message that it normally
gives when this happens with member functions, whereas since it doesn't work
with constructors, it really should have a different error message, but it
doesn't.
- Jonathan M Davis
t recall what
he said. I also don't know if it was closed as "won't fix" or remember much
that would make it easy to find, unfortunately. :|
But there is a technical reason for the limitation, even if I don't remember
what it is.
- Jonathan M Davis
On Tuesday, March 18, 2025 1:19:49 PM MDT bauss via Digitalmars-d-learn wrote:
> On Tuesday, 18 March 2025 at 18:04:12 UTC, Steven Schveighoffer
> wrote:
> > On Tuesday, 18 March 2025 at 07:42:37 UTC, Jonathan M Davis
> > wrote:
> >> The base class constructors are n
en in Phobos v3,
but that's quite a ways off. So, if you can't make std.socket work the way
that you need, you'll either need to find a solution on code.dlang.org or
make your own using the underlying C calls.
- Jonathan M Davis
than its name as a string,
since that would bypass this whole issue (as well as negate the need to use
a mixin to get the symbol for the function).
However, there is a pretty simple workaround. Just get the symbol from
within the parent function instead of within the nested function, e.g.
alias parentFunction = mixin(__FUNCTION__);
void dg()
{
// access parentFunction here
}
It even works if the nested function is static.
- Jonathan M Davis
On Monday, March 17, 2025 6:28:19 PM MDT Jonathan M Davis via
Digitalmars-d-learn wrote:
> On Sunday, February 16, 2025 12:38:09 AM MDT Anonymouse via
> Digitalmars-d-learn wrote:
> > I want to get a reference to a parent function from inside a
> > nested function. I ne
On Sunday, March 16, 2025 9:22:04 AM MDT Ian via Digitalmars-d-learn wrote:
> On Tuesday, 25 February 2025 at 00:34:45 UTC, Jonathan M Davis
> wrote:
> > For strings, the way that you normally do constants is with
> > enum, e.g
> >
> > enum foo = "dlang"
that the language itself uses ] or ) in any of its
syntax to indicate how open an interval is, but it implies that either
something we have was not written clearly enough (which is very possible) or
that WhatMeWorry misinterpreted it in an unusual way.
- Jonathan M Davis
a string has the same result. So,
typically, enums are used for constants which are strings - the same with
int and other types which involve no allocations - whereas for other types
of arrays, an immutable static variable is generally better.
- Jonathan M Davis
7;m not aware of any reason to prefer a static immutable string over an enum
unless you actually need to take its address for some reason.
- Jonathan M Davis
e of -1 to uint. So, as long as the value fits in 32 bits, the
conversion will work even if gets screwed up by the conversion between
signed and unsigned.
- Jonathan M Davis
On Wednesday, February 19, 2025 11:24:36 PM MST IchorDev via
Digitalmars-d-learn wrote:
> On Saturday, 15 February 2025 at 10:09:39 UTC, Jonathan M Davis
> wrote:
> > I think that you need to be clearer about what you're trying to
> > do. If a module-level variable is no
On Wednesday, February 19, 2025 7:48:48 PM MST Jonathan M Davis via
Digitalmars-d-learn wrote:
> So you should probably either just make your code operate on ranges of
> dchar, or you'll need to wrap your ranges using byChar or byCodeUnit in
> order to get ranges of char. A
the original range, but a large percentage of range-based functions
are lazy and will return wrapped ranges. So, depending on what you're doing,
it's going to be difficult to do a bunch of range-based operations and then
get a string at the end of the result witout allocating a new string - even
if strings were treated as ranges of their actual element type.
- Jonathan M Davis
Andrei when
he wrote them, which makes it more likely that something would have been
missed.
- Jonathan M Davis
On Sunday, February 16, 2025 4:54:46 AM MST ShadoLight via Digitalmars-d-learn
wrote:
> On Sunday, 16 February 2025 at 05:39:07 UTC, Jonathan M Davis
> wrote:
> > _especially_ when VRP comes into play, because then you get
> > nonsense like foo(1) calling the bool overload.
&g
;obvious" stuff work - e.g.
something like
ubyte[] arr = [1, 2, 3];
it's resulted in all kinds of confusing inconsistencies in the language. So,
while we learned from C++ with this stuff to some degree, we've still made
plenty of mistakes with this sort of thing.
- Jonathan M Davis
ments rather than
just one, it could make the AA approach faster. So, ultimately, benchmarking
with your particular data set would be required to know for sure which would
be faster, but for a single search, the AA will probably lose.
- Jonathan M Davis
S. Either way, D itself doesn't
do anything with TLS, much as we often talk about non-shared variables being
thread-local.
- Jonathan M Davis
tuff unless they're simply bindings for C stuff,
because without a security expert verifying them, it's _really_ easy to have
security issues even if they're otherwise great libraries, and you're
unlikely to find a library with that kind of vetting on code.dlang.org.
- Jonathan M Davis
rence based on the context, since the return value
would just convert to I without any special casing required - whereas
function pointers require some special casing in order to compile (similar
to how ubyte[] requires some special casing to support [1, 2, 3]).
So, the spec could definitely be clearer, but it does seem to be talking
entirely about adjusting the return type of a lambda that already has a
return type, not about inferring the initial return type of the lambda based
on its context. It has to have an initial return type to adjust first.
- Jonathan M Davis
On Friday, January 31, 2025 3:45:55 PM MST Kyle Ingraham via
Digitalmars-d-learn wrote:
> On Thursday, 30 January 2025 at 04:44:02 UTC, Jonathan M Davis
> wrote:
> > What we really need is something like tryTo that returns a
> > Nullable which has no value when the conversi
can't simply be a wrapper around tryTo if you want to provide any
information about why it failed like it currently does). But to's
implementation is probably going to get a major overhaul for Phobos v3
anyway to try to reduce how many template instantiations it incurs. Either
way, tryTo is definitely planned as part of Phobos v3.
- Jonathan M Davis
ve to test the
value that you're converting first to make sure that the conversion won't
fail - e.g. something like all!isDigit(input) if you're converting a string
to an int.
- Jonathan M Davis
On Tuesday, January 28, 2025 10:41:31 AM MST DLearner via Digitalmars-d-learn
wrote:
> On Tuesday, 28 January 2025 at 15:00:13 UTC, Jonathan M Davis
> wrote:
> [...]
>
> >
> > -betterC was originally intended to be a tool for making it
> > easier to port C code to
On Tuesday, January 28, 2025 8:04:36 AM MST Dennis via Digitalmars-d-learn
wrote:
> On Tuesday, 28 January 2025 at 15:00:13 UTC, Jonathan M Davis
> wrote:
> > but we provide no guarantees that any code that works with
> > -betterC right now will continue to do so, and we do not
e pay as you go -
that is, if it really doesn't need something, it doesn't pull it in, so you
then hopefully you don't pull in code that you're not using - and that would
naturally make more stuff work with -betterC, but we're not going to
explicitly support -betterC with druntime or Phobos.
- Jonathan M Davis
On Sunday, January 26, 2025 4:41:53 PM MST DLearner via Digitalmars-d-learn
wrote:
> On Monday, 20 January 2025 at 19:54:19 UTC, Jonathan M Davis
> wrote:
> [...]
> > Also, there's really no reason to be doing anything with char[]
> > instead of string unless you&#
> They should be immutable, but do they have some other, more
> specific property?
Immutability is not a requirement for CTFE.
I suggest that you read this article:
https://wiki.dlang.org/Compile-time_vs._compile-time
- Jonathan M Davis
for example doesn't raise any error :
>
> ```
> >> cp source /dev/null
> >> echo $?
> 0
> ```
>
Per copy's documentation, it preserve's the file's timestamps, and looking
at where the exception is coming from, setting the access and modification
times on /dev/null is apparently illegal (which isn't particularly
surprising).
- Jonathan M Davis
utating the elements, which
would violate the type system guarantees - since immutable values are never
supposed to be mutated, and the compiler will potentially make the
assumption that an immutable value was not mutated (string is an alias for
immutable(char)[], and string literals are strings). If you _do_ need to
mutate the string for some reason, then use dup to get a mutable copy rather
than casting the literal, e.g.
char[] wkVarName = "IntVar3".dup;
- Jonathan M Davis
es have been blurred as the functionality
of some of the functions involved has expanded. So, understanding the basic
distinctions between the various modules helps make it possible to find
stuff more easily, but functions aren't always where you might expect them
to be, depending on what your expectations are.
- Jonathan M Davis
e statements,
thinking about how they're lowered to try-catch blocks may help you
understand why they work the way that they do. And if you can't do what you
want to do with a try-catch block, then you definitely can't do it with
scope statements, since that's what they ultimately are.
- Jonathan M Davis
al code is doing. Often,
it's matter of refactoring your code so that the core logic can be tested
separately, but that really depends on what your code is doing.
- Jonathan M Davis
t I haven't seen many cases where
using a struct with no members in an actual program made much sense.
- Jonathan M Davis
ich used inout, it
probably wouldn't have worked properly when used with inout later.
So, I should probably add inout to the list of things that the Phobos v3
test helpers will need to include help for to at least try to make it easier
to catch.
- Jonathan M Davis
must be cast to something
else. If you want to access the data as bytes, then typically, casting to
ubyte[] would be the appropriate thing to do. Then you can use
std.bitmanip's stuff on it to convert groups of bytes to int or short or
some other integral type.
- Jonathan M Davis
e code is wrong, because
the lengths of the slices don't match in
b[0 .. a.length-1] = a[];
You'll get a RangeError being thrown when you run the code.
- Jonathan M Davis
g to make foo a const member function even though it looks like
you're saying that you want const int. To get that, you need
const(int) foo() { ... }
- Jonathan M Davis
e type causes confusion like you're
experiencing. However, it's likely allowed for similar reasons to why it's
legal to call static member functions on an instance rather than requiring
that they be called on the type (which I'm inclined to argue was a bad
design decision, but it's what we have).
- Jonathan M Davis
x27;s the same between static variables and enums is that if
they're directly initialized, that value has to be known at compile time.
So, they both can be used in a variety of circumstances where you need to
guarantee that something is done at compile time.
- Jonathan M Davis
n just created a script that runs dub and then
symlinks the files (or an installation script which symlinks the files in my
bin directory when it copies them there). Even if you go with #2, you might
want a helper script to be able to just build them all with one command.
- Jonathan M Davis
Hello,
I'm trying to test out a program I wrote on a new computer
with a fresh install of WSL. Part of the idea of doing this is
to add installation instructions for people who don't have
Phobos. I've gone through what I expected to be the proper
install procedure:
```
sudo apt install
would argue that in this case, auto just makes the code
harder to understand. The documentation can easily say that the return type
is ubyte in spite of it saying auto, but it's just as easy to type ubyte,
and then the return type is immediately obvious instead of requiring
additional documentation just to say what's being returned. So, while auto
is used quite heavily in D code, I wouldn't expect many folks to choose to
use auto for this particular function.
- Jonathan M Davis
hat it wouldn't ever make sense to change this particular
function in a way that the return type needed to change, and returning uint
should ultimately work just fine, but I think that restricting the surface
area where narrowing casts are likely to happen will ultimately reduce the
risk of bugs, and I think that it's pretty clear that there will be less
casting overall if the casting is done here instead of at the call site
unless the function is barely ever used.
- Jonathan M Davis
t; -1, which is closer but not right either.
Well, this is what the spec says:
https://dlang.org/spec/expression.html#division
- Jonathan M Davis
rogram is terminated instead of continuing in an invalid state.
- Jonathan M Davis
On Monday, September 9, 2024 6:40:07 PM MDT kookman via Digitalmars-d-learn
wrote:
> On Tuesday, 10 September 2024 at 00:27:43 UTC, Jonathan M Davis
>
> wrote:
> > On Monday, September 9, 2024 5:46:18 PM MDT kookman via
> >
> > Digitalmars-d-learn wrote:
> >>
lance, it looks like the part of case 5 which explicitly catches the
Exception and the part that uses assertThrown should behave the same, but
your example doesn't actually compile (you didn't include a definition for
base32Alphabet), so it's not actually possible to reproduce you
ent, but it's arguably best practice to just avoid expressions that
modify a variable while also evaluating that variable in another part of the
expression. It makes the code clearer and avoids any order-of-evaluation
issues which may exist in the language.
- Jonathan M Davis
On Friday, August 16, 2024 10:37:45 AM MDT Nick Treleaven via Digitalmars-d-
learn wrote:
> On Friday, 16 August 2024 at 16:30:09 UTC, Jonathan M Davis wrote:
> > Whether the result of dup is then able to be implicitly
> > converted to immutable based on whether the operation is p
sult is used.
So, dup may very well work in this particular case, but in the general case,
you really want to be using idup if you want immutable. And in this
particular example, all it would take to make the result not immutable would
be to use auto instead of string.
- Jonathan M Davis
On Friday, July 26, 2024 2:17:21 AM MDT Dom DiSc via Digitalmars-d-learn
wrote:
> On Thursday, 25 July 2024 at 13:07:03 UTC, Jonathan M Davis wrote:
> > On Thursday, July 25, 2024 6:00:58 AM MDT Dom DiSc via
> >
> >> But a parameter given by value is ALWAYS a copy.
>
ors, an rvalue constructor
would become a move constructor, though since it's not necessarily obvious
that that's what it is, and such constructors already exist as normal
constructors, there are some objections to making such a change. But of
course, we'll have to see what ultimately happens with that.
- Jonathan M Davis
dds via scope (since without the extra checks, you could easily take
that address and pass it around, letting it escape the lifetime of the
reference).
- Jonathan M Davis
lates with a tail-const version similar
to what we get with dynamic arrays, but that really only makes sense for
certain types such as ranges.
But either way, it would cause quite a few problems if IFTI started
instantiating templates in general with mutable instead of the actual type
that it's given, because it's extremely common that const and immutable
types cannot be converted to mutable.
- Jonathan M Davis
ert(is(typeof(arr) == const(int[])));
static assert(is(typeof(arr[]) == const(int)[]));
So, if you have something like
immutable string foo = "hello";
and you pass it to a templated function, the type will be treated as string,
whereas with a user-defined type - or with any built-in types which aren't
dynamic arrays - the templated function is instantiated with exactly the
type that you pass it.
- Jonathan M Davis
u know enough to suspect that something
along those lines might be the problem, I bet that most of us would not
immediately come to that conclusion. It's just too subtle. And all to avoid
typing a couple of characters.
- Jonathan M Davis
nd you could
easily spend more time trying to optimize your build times than you would
ever save by trying generate the string more efficiently, but it's your
code.
- Jonathan M Davis
ully lead to the file being updated (and if you're feeling particularly
motivated, you can always open a pull request -
https://github.com/dlang/dmd/).
- Jonathan M Davis
1 - 100 of 1087 matches
Mail list logo
