The language does not prevent taking the address of a private
symbol and escaping it.
The alias case isn't (ie shouldn't be) different.
artur
-
import mver;
static if (ver.linux && !ver.D_LP64) {
/* ... */
}
-
artur
On 04/28/16 10:28, Adrian Matoga via Digitalmars-d wrote:
> On Wednesday, 27 April 2016 at 18:34:18 UTC, Artur Skawina wrote:
>> [...]
>>
>>ref Ex1() { return e1.someProperties.someModulusX; }
>
> Unless any of the properties is an enum or, well, a @property
foreach (i; ...) foreach (j; ...) {
M[...] = Ex1 > Ex2 ?
1/v^^2 * sqrt(v * (Ex1 + Ex2)^^2 + v^^2 * (Ey1 - Ey2)^^2) :
1/v^^2 * sqrt(v * (Ex1 + Ex2)^^2 + v^^2 * (Ey1 + Ey2)^^2) ;
}
}
artur
n inferred
return type is still a function (eg you can instantiate the former and
you can take the address of the latter).
artur
t; changes, and finally after that it goes to Linus, and overall after passed by
> the board it's almost approved by Linus too.
I'd just ignore this, but somebody might actually believe it's true...
Linux development works because Linus is right often enough.
It really is that simple.
artur
logCall!foo(true);
Which will happily accept:
bool foo(ref bool a) { return a=false; }
And, yes, it can be dealt with via a bit of introspection, but
nobody will bother in practice (consider that 'f' may be
overloaded). So it doesn't really work for non-trivial or
generic code.
artur
immutable table = [
["row1.1", "row1.2 ", "row1.3"],
["row2.1", "row2.2", "row2.3"],
["row3.1", "row3.2", "row3.3 "],
["row4.1", "row4.2", "row4.3"],
["row5.1", "row5.2", "row5.3"],
];
fmttable(table);
int i;
for (i=0; i < 100; ++i) {
fmttable!sink0(table);
}
sink(i, "\n");
}
artur
On 10/14/15 15:32, Atila Neves via Digitalmars-d wrote:
> On Wednesday, 14 October 2015 at 12:42:23 UTC, Artur Skawina wrote:
>> On 10/14/15 10:26, Atila Neves via Digitalmars-d wrote:
>>> On Monday, 28 September 2015 at 20:25:21 UTC, Atila Neves wrote:
>>>> I'
e don't consider ad hoc hacks to
be cost effective, but actually counterproductive.
artur
sty bugs, because you might not have
immediately noticed that you're operating on an already unlocked
object.
artur
On 10/05/15 17:53, Marco Leise via Digitalmars-d wrote:
> Am Sun, 04 Oct 2015 00:08:39 +0200
> schrieb Artur Skawina via Digitalmars-d
> :
>
>>static ctfe = ctfeArr!( iota(256).map!isDigit() );
>>
>>immutable typeof(R.front)[R.array().length] ctfeArr(alias R)
static ctfe = ctfeArr!( iota(256).map!isDigit() );
immutable typeof(R.front)[R.array().length] ctfeArr(alias R) = R.array();
[`array` is only required because of compiler issues, yes.]
artur
On 09/27/15 13:48, Marco Leise via Digitalmars-d wrote:
> Am Sat, 26 Sep 2015 19:58:14 +0200
> schrieb Artur Skawina via Digitalmars-d
> :
>
>> `allow` is the default state and always safe; for the cases
>> where it's /undesirable/, there is noinline.
>
> No
e info in that file really is as unique as Manu
says, plus because of this thread it already became much more accessible,
so it's possible that the issue has been already solved. But every
other `free-but-entangled-with-non-free` part of DMD has the same problem.
"Let's look inside works we can't legally use, just in case there's some
usable part inside" is not a viable option. Really.
artur
in D, except in cases it's used to extend
the language in a non-implementation-specific way.
(C/C++ have the preprocessor, that's why it works there)
> extend it so that it offers more options:
>
> * no
> * force
> * flatten
> (And maybe an additional 'allow' that convinces the compiler
> that inlining is safe.)
`allow` is the default state and always safe; for the cases
where it's /undesirable/, there is noinline.
artur
but w/o any non-open-source code. Nobody else can do that (ie the
result wouldn't be sufficiently trustworthy).
Open source code hidden somewhere deep inside a non-free compiler
implementation might just as well not exist, as noone interested
will be willing to look for it there.
artur
ect.d".
void main() {
std.stdio.writeln("Hello world!");
mod.core.stdc.stdio.printf("%d\n", 42);
}
SCNR
artur
extern UndeclaredStruct blah;
> auto p = &blah;
>
> which doesn't compile. Why not? Neither the size nor any default initialiser
> is needed.
Yeah; workaround (plus mangling and TLS fix):
struct UndeclaredStruct {}
extern extern (C) __gshared UndeclaredStruct blah;
auto p = &blah;
artur
(hint: "mixin"). But, unlike
support for with-declarations (which would be a significant
improvement) I'm not sure if with-expression would make
sense (and the lifetimes might be too unintuitive --
they'd be different for with-statements and -expressions).
artur
On 07/24/15 23:32, Jonathan M Davis via Digitalmars-d wrote:
> On Friday, 24 July 2015 at 20:57:34 UTC, Artur Skawina wrote:
>> The difference is that right now the developer has to write a unit-test per
>> function that uses `hasPrefix`, otherwise the code might not even be
On 07/24/15 20:29, Walter Bright via Digitalmars-d wrote:
> On 7/24/2015 4:55 AM, Artur Skawina via Digitalmars-d wrote:
>> Basically, it can work like this:
>>
>> - traits, like your 'hasPrefix', check that 'T' implements an
>>interface (defin
ut here. If the new code /requires/
extra functionality then it needs to be explicitly requested.
This is no different from how D classes work -- you either have
to request a subclass to use it, or check with `cast(SubClass)`
at run-time. Traits work at compile-time, that's all.
artur
On 06/28/15 16:21, Joakim via Digitalmars-d wrote:
> On Sunday, 28 June 2015 at 13:43:39 UTC, Artur Skawina wrote:
>> On 06/28/15 05:06, Joakim via Digitalmars-d wrote:
>>> So you're trying to avoid writing this?
>>>
>>> version(linux) version(D_LP
(F(A.init));
artur
the problem can easily be solved, even if Rust and
C++ concepts don't support this functionality.
artur
syntax would be natural in D (even C compilers have this as an
extension, eg gcc's "statement expressions").
> I meant
> auto foo = { mixin foo!T f; return &f.foo; }();
> and then use the function normally.
That may work for function, which have effectively infinite
lifetime, but is not a good idea for other objects.
artur
writeln(")");
return fun(args);
}
}
And, btw, one of your asserts in that dreamy example has an
off-by-one bug. Of course the only reason I spotted it is because
I actually ran the code. ;) [1]
artur
[1] My old static-foreach hack makes i
On 06/08/15 17:14, Jeffrey Tsang via Digitalmars-d wrote:
> On Sunday, 7 June 2015 at 14:17:45 UTC, Artur Skawina wrote:
>> On 06/07/15 11:05, Jeffrey Tsang via Digitalmars-d wrote:
>>> I use a mixin template to define exactly one symbol, and at instantiation I
>>&
till, 'auto' isn't as bad as 'static', which D redefined to mean
something different than in C/C++, and did this so subtly that
the C version will still compile, giving unexpected results without
even a warning.
artur
auto l = argv.length;
mixin Tmpl!() a;
assert(a.Tmpl==l);
//assert(a==l);
}
to work. That would probably be enough, make sense and have
no serious backward compat issues.
artur
On 06/03/15 01:41, ketmar via Digitalmars-d wrote:
> On Tue, 02 Jun 2015 18:49:09 +0200, Artur Skawina via Digitalmars-d wrote:
>
>> On 06/02/15 14:21, ketmar via Digitalmars-d wrote:
>>> this opens a can of worms. should this be accepted too:
>>> enum doItFinal
als.
D has enough unnecessary special cases as it is (like built-in types
being special).
artur
ad of storing the pointer, we store the offset to the struct
> itself. This works as long as the SPtr instance stays co-located with its
> target.
auto a = s.y;
// this 'a' now implicitly converts to 'int', but...
void g(T)(T a);
g(s.y); // ditto.
artur
c assert(is(typeof(Foo!(short, ubyte, bool).value)==int));
What all these proposals seem to be about is:
a) better introspection (ie exposing a (preferably simplified and std) AST)
b) AST injection
c) "better" syntax
d) better "optimizations", meaning skipping the emission of code and data
that is never used at runtime.
artur
On 05/26/15 18:16, Timon Gehr via Digitalmars-d wrote:
> On 05/26/2015 06:13 PM, Artur Skawina via Digitalmars-d wrote:
>> On 05/26/15 14:54, Timon Gehr via Digitalmars-d wrote:
>>> On 05/26/2015 06:35 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
>>> " wrote:
&g
returning void vs. returning the lvalue. The
> expression/statement distinction is unnecessary.
int a, b, c;
void f();
f(a=b);
void g(T...)(T) {}
g(a=b);
// and, even when 'void' is not a first class type:
void h(int);
h(((a=b), c));
artur
On 03/17/15 22:18, Baz via Digitalmars-d wrote:
> On Tuesday, 17 March 2015 at 21:06:04 UTC, Artur Skawina wrote:
>> On 03/17/15 20:47, deadalnix via Digitalmars-d wrote:
>>>
>>> Not that much. But q{ string are a pain in the ass.
>>
>> Why? I'm not
acedTokenSequence )*
"}"
That's PEG, but the mapping to code should be fairly obvious.
For syntax highlighting purposes it can actually be even simpler - it's
enough to treat a `q{` token just like a `{`; everything that follows
will be valid D tokens.
artur
ded DSLs.
OTOH this would be just one more random weekly language change, so why not?
artur
On 02/23/15 21:21, Charles via Digitalmars-d wrote:
> My solution (150 characters, 15 points):
>
> void main(){import std.stdio;int t,n;readf(" %d",&t);while(t--){readf("
> %d",&n);real a=0,i=0;for(;i
urn attributes).
artur
On 01/26/15 23:10, Walter Bright via Digitalmars-d wrote:
> On 1/26/2015 1:45 PM, Artur Skawina via Digitalmars-d wrote:
>>> Just 'no' on context-sensitive tokens.
>> C. C++. D. Windows. Pascal. System. exit. success. failure.
>
> They're never keywords.
H
alid as identifiers for e.g. variables.
>
> Just 'no' on context-sensitive tokens.
C. C++. D. Windows. Pascal. System. exit. success. failure.
artur
On 12/31/14 22:35, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Dec 31, 2014 at 10:34:07PM +0100, Artur Skawina via Digitalmars-d
> wrote:
>> On 12/18/14 16:43, Steven Schveighoffer via Digitalmars-d wrote:
>>> We currently have the ability to do opIndex for simulating an ar
s.key = 2;
s.val = "yada";
s[0] = 42;
s[1] = "etc";
}
SCNR. Happy new year!
artur
mixin("_parms."~M) = b;
return this;
}
auto opDispatch()() @property {
return mixin("_parms."~M);
}
}
}
return FParm();
}
artur
in the D dialects supported
by recent frontend releases) determined from *all* returned expression.
What would be the advantage of propagating/inferring only the type, but not
the lvalueness?...
artur
On 08/12/14 17:51, Tofu Ninja via Digitalmars-d wrote:
> On Tuesday, 12 August 2014 at 08:46:33 UTC, Artur Skawina via Digitalmars-d
> wrote:
>>struct namedGlobalArray(string name, T) {
>> template opDispatch(string M) { static T opDispatch; }
>>}
> I lo
rage(string var)(Nullable!T x)
> {
> static T data;
> if(!x.isNull) data = x;
> return data;
> }
> }
> There might be a way to do it without Nullable but I couldn't
> think of one...
struct namedGlobalArray(string name, T) {
template opDispatch(string M) { static T opDispatch; }
}
artur
{ A, D },
{ B, E },
{ C, E2.C },
];
return r;
});}}();
Not pretty, but sometimes useful when you have a lot of such elements
and/or when they are generated from DSLs.
artur
On 08/06/14 22:57, via Digitalmars-d wrote:
> On Wednesday, 6 August 2014 at 17:36:00 UTC, Artur Skawina wrote:
>>if (0)
>> assume(0);
>>
>> Yes, `assume` could be defined in a way that would make this
>> always a compile error. But then `assume(0)` wou
On Wednesday, 6 August 2014 at 17:03:45 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 6 August 2014 at 16:59:18 UTC, Artur Skawina
wrote:
No, an assume(false) in a program only means that every _path_
_leading_to_that_statement is 'unsound'. For practical purposes
it's better to
optimize based on the (un)reachability,
but the behavior in no longer undefined.
artur
as long as the observable behavior does
not change. `Assume` removes that restriction as soon as a failing
assert is reached.
artur
ver happens the CPU can start
executing any random instructions. That's ok, since you explicitly told
the compiler that this situation will never occur. Hence, it can also
skip generating any code for any path that unconditionally leads to a
failing `assume` directive. Because it is all dead code that will never
be executed, as long as all `assume` conditions are true.
artur
=> x * x * x + 2 * x * x + 3 * x)()
better than
(x => x * x * x + 2 * x * x + 3 * x)(1 + 2 * 3)
?
artur
On 08/03/14 17:14, Iain Buclaw via Digitalmars-d wrote:
> On 2 August 2014 14:54, Artur Skawina via Digitalmars-d
>> But I'm not sure if exposing `attribute` like that would be
>> a good idea (until now I was always using a static import, so
>> name clashes were not a pro
On 08/03/14 17:06, Walter Bright via Digitalmars-d wrote:
> On 8/2/2014 1:06 PM, Artur Skawina via Digitalmars-d wrote:
>> There's nothing wrong with `assume`, it's very useful for optimizations.
>> But it's too dangerous to tack `assume` onto `assert`. If they are
Effectively you would always have to assume that
assert==assume. So a compiler switch wouldn't really improve the situation.
artur
On 08/02/14 21:19, Walter Bright via Digitalmars-d wrote:
> On 8/2/2014 6:20 AM, Artur Skawina via Digitalmars-d wrote:
>> The bug was _introduced_ by the assert, the code was 100% correct.
>
> Asserts are part of the code, and writing incorrect asserts is writing buggy
> cod
On 08/02/14 17:08, Andrei Alexandrescu via Digitalmars-d wrote:
> On 8/2/14, 5:44 AM, Artur Skawina via Digitalmars-d wrote:
>>auto fx(ubyte* p, size_t len) @safe {
>>assert_(len>0);
>>if (len>=1)
>> return p[0];
>>retur
On 08/02/14 15:32, Tobias Pankrath via Digitalmars-d wrote:
> On Saturday, 2 August 2014 at 13:21:07 UTC, Artur Skawina via Digitalmars-d
> wrote:
>> On 08/02/14 14:54, Tobias Pankrath via Digitalmars-d wrote:
> If there is a wrong assert in the code, it's not perfectly
On 08/02/14 15:24, Iain Buclaw via Digitalmars-d wrote:
> On 2 August 2014 12:12, Artur Skawina via Digitalmars-d
> wrote:
>> -
>>static import gcc.attribute;
>>enum inline = gcc.attribut
l be found in testing, but
that's far from certain.
We use high level languages to (aot) protect ourselves from our own
mistakes. Just because I can write:
S* p = 0x12345678;
does not mean that the compiler has to accept it.
artur
On 08/02/14 14:12, Tobias Pankrath via Digitalmars-d wrote:
> On Saturday, 2 August 2014 at 11:12:42 UTC, Artur Skawina via Digitalmars-d
> wrote:
>>
>> _`assume` is extremely dangerous_.
>
> You sure can come up with an example where -release (and only with relea
tremely dangerous_. Redefining `assert` to include `assume`
would result in D's `assert` being banned from the whole code base, if 'D'
even would be consider a 'sane' enough language to use...
artur
at is a fact. :)
The english definition of 'assert' is *completely irrelevant*.
Really.
artur
On 08/01/14 04:33, Daniel Murphy via Digitalmars-d wrote:
> "Artur Skawina via Digitalmars-d" wrote in message
> news:mailman.324.1406835164.16021.digitalmar...@puremagic.com...
>
>> > The corner case is "assert(0)". It means "if the program got to h
On 08/01/14 00:08, Walter Bright via Digitalmars-d wrote:
> On 7/31/2014 9:02 AM, Artur Skawina via Digitalmars-d wrote:
>>>> The solution is to tell the compiler that you really need that newly
>>>> (over-)written data. Eg
>>>>
>>>>
On 07/31/14 19:22, John Colvin via Digitalmars-d wrote:
> On Thursday, 31 July 2014 at 15:26:27 UTC, Artur Skawina via Digitalmars-d
> wrote:
>> On 07/31/14 15:44, Daniel Gibson via Digitalmars-d wrote:
>>> And don't forget this (rather old) case:
>>> https://g
27;s vaguely defined, overloaded, and not currently treated that way.
Arguably it could mean 'this path won't ever be reached, trust me', but
redefining it now is obviously not possible. (doing this would of course
make assert(0) extremely dangerous)
artur
On 07/31/14 17:37, Daniel Gibson via Digitalmars-d wrote:
> Am 31.07.2014 17:26, schrieb Artur Skawina via Digitalmars-d:
>> On 07/31/14 15:44, Daniel Gibson via Digitalmars-d wrote:
>>> And don't forget this (rather old) case:
>>> https://gcc.gnu.org/bugzilla/sh
iler that you really need that newly
(over-)written data. Eg
asm {"" : : "m" (*cast(typeof(password[0])[999]*)password.ptr); }
(yes, stdizing compiler barriers would be a good idea)
artur
@safe.
artur
On 07/31/14 02:31, Walter Bright via Digitalmars-d wrote:
> On 7/30/2014 3:53 PM, Artur Skawina via Digitalmars-d wrote:
>> No, with the assert definition you're proposing, it won't. It would
>> be allowed to optimize away the bounds check. And this is just one of
>>
On 07/31/14 01:14, Andrei Alexandrescu via Digitalmars-d wrote:
> On 7/30/14, 3:41 PM, David Nadlinger wrote:
>> On Wednesday, 30 July 2014 at 22:30:59 UTC, Walter Bright wrote:
>>> On 7/30/2014 3:20 PM, Artur Skawina via Digitalmars-d wrote:
>>>>void f(ubyte[]
On 07/31/14 00:31, Walter Bright via Digitalmars-d wrote:
> On 7/30/2014 3:20 PM, Artur Skawina via Digitalmars-d wrote:
>> On 07/30/14 23:42, Walter Bright via Digitalmars-d wrote:
>>> @safe's promise is one of memory safety, not a promise of program
>>> correct
safe's promise is one of memory safety, not a promise of program correctness.
void f(ubyte[] a) @safe { assert(a.length>99); a[88] = a[77]; }
artur
On 07/30/14 13:56, Daniel Murphy via Digitalmars-d wrote:
> "Artur Skawina via Digitalmars-d" wrote in message
> news:mailman.217.1406713015.16021.digitalmar...@puremagic.com...
>
>> `assert` is for *verifying* assumptions. It must not allow them
>> to leak/esc
special case; for true asserts it would
be)
`assert` is for *verifying* assumptions. It must not allow them
to leak/escape. Otherwise a single not-100%-correct assert could
defeat critical runtime checks.
'assume' would be useful, but dangerous, like a reinterpret cast;
it would need to be @trusted.
artur
On 07/23/14 09:16, Don via Digitalmars-d wrote:
> On Monday, 21 July 2014 at 21:10:43 UTC, Artur Skawina via Digitalmars-d
> wrote:
>> Actually, C/C++ could get away with treating overflow during constant
>> folding as an error (or at least emitting a warning) because of the
&g
On 07/22/14 18:39, Iain Buclaw via Digitalmars-d wrote:
> On 22 July 2014 12:40, Artur Skawina via Digitalmars-d
> wrote:
>> On 07/22/14 08:15, Iain Buclaw via Digitalmars-d wrote:
>>> On 21 Jul 2014 22:10, "Artur Skawina via Digitalmars-d"
>>> ma
On 07/22/14 17:31, via Digitalmars-d wrote:
> On Tuesday, 22 July 2014 at 11:40:08 UTC, Artur Skawina via Digitalmars-d
> wrote:
>> obey the exact same rules as RT. Would you really like to use a language
>> in which 'enum x = (a+b)/2;' and 'immutable x = (a+b)/2
On 07/22/14 08:15, Iain Buclaw via Digitalmars-d wrote:
> On 21 Jul 2014 22:10, "Artur Skawina via Digitalmars-d"
> mailto:digitalmars-d@puremagic.com>> wrote:
>> For D that is not possible -- if an expression is valid at run-time
>> then it should be valid at
On 07/22/14 05:12, via Digitalmars-d wrote:
> On Monday, 21 July 2014 at 21:10:43 UTC, Artur Skawina via Digitalmars-d
> wrote:
>
>> For D that is not possible -- if an expression is valid at run-time
>> then it should be valid at compile-time (and obviously yield the same
&
On 07/21/14 21:53, via Digitalmars-d wrote:
> On Monday, 21 July 2014 at 19:33:32 UTC, Artur Skawina via Digitalmars-d
> wrote:
>> Disallowing integer overflow just at CT is not (sanely) possible
>> in a language with D's CTFE capabilities. (Would result in code
>&g
not ctfe-able)
artur
On Thursday, 17 July 2014 at 08:50:12 UTC, John Colvin wrote:
> there may be ways of telling backends that it is defined and we may be using
> those ways, I don't know.
For GDC, it's the '-fwrapv' switch, but it's not enabled by default for D.
artur
to volatile_. Ditto
for RTTI, unwinding tables, dead code etc. Those issues needs to be dealt
with anyway.
artur
On 07/16/14 15:02, Johannes Pfau via Digitalmars-d wrote:
> Am Tue, 15 Jul 2014 19:44:51 +0200
> schrieb Artur Skawina via Digitalmars-d :
>
>> Could you show one (concrete) example where using 'volatile' is better
>> than my approach?
>
> I experimented a li
. The
result are many half-finished features, every one with some kind of problem.
Could a 'volatile' type qualifier be made to work, and are there technical
problems with the DIP? Yes, and No. I'm not ignoring the details; I probably
agree with most, if not all, of them.
I'm saying the DIP is a good answer, to the wrong question.
artur
[1] Which I didn't respond to, to avoid derailing the thread. ;)
On 07/15/14 19:11, Johannes Pfau via Digitalmars-d wrote:
> Am Tue, 15 Jul 2014 19:03:52 +0200
> schrieb Artur Skawina via Digitalmars-d :
>
>> Compiler barriers are not "workarounds". "volatile" is not a "better
>> solution". It's used i
On 07/15/14 19:07, bearophile via Digitalmars-d wrote:
> Artur Skawina:
>
>> You can already express
>> all the described volatile semantics in GDC's D dialect, in a
>> completely portable way and without using a single asm instruction.
>
> What
#x27;s missing is just a defined standard interface which can be
supported by all D compilers.
artur
heap alloc
scope callback = {a = 42;}; // stack (ie normal) alloc
testA(callback);
testB(callback);
}
Then there are lazy args, which are basically scope delegates,
but with no way to turn off 'scope' and no escape protection.
Trying to tack 'borrowed' on 'ref' is not a good idea. (would
require new restrictions, hence not backwards compatible; it can't
be a @safe-only thing, `borrowed` affects lifetimes etc)
artur
ody
from contributing, so I don't want to list "potential dangers",
That would only lead to discussions about how real or serious they
are; it's a very subjective matter.
artur
much existing code will not be trivial. Also, the parametrization
and negation issues should probably be addressed at the same time,
otherwise even more not fully backwards compatible changes may be
necessary in the future.
artur
d soemwhere hidden on
> my long TODO list, but there are too many other important things to
> look after for the time being. :)
Any chance of some kind of progress on the inlining front in the near
future?
artur
ften end up having to go back and add '@global'
annotations to the whole call stack, once it turns out to be necessary
to use some D-impure code. Which can affect already published APIs etc.
artur
1 - 100 of 509 matches
Mail list logo
