On 2/7/15 8:21 PM, H. S. Teoh via Digitalmars-d wrote:
Come to think of it, is there any point in making malloc @safe/@trusted
at all? I don't think it's possible to make free() @safe, so what's the
purpose of making malloc callable from @safe code? Unless you make a
ref-counted wrapper of some s
On Sat, Feb 07, 2015 at 08:15:05PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 2/7/15 8:00 PM, H. S. Teoh via Digitalmars-d wrote:
> >On Sat, Feb 07, 2015 at 06:19:19PM -0800, Andrei Alexandrescu via
> >Digitalmars-d wrote:
> >[...]
> >>private @system T[] mallocUninitializedArrayImp
On Sat, Feb 07, 2015 at 08:14:39PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 2/7/15 7:52 PM, tcak wrote:
> >One of the reasons why I use C functions is that I expect same
> >behaviour from D code what I would expect from C. I don't think it is
> >a good idea to make wrapper on top o
On 2/7/15 8:00 PM, H. S. Teoh via Digitalmars-d wrote:
On Sat, Feb 07, 2015 at 06:19:19PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]
private @system T[] mallocUninitializedArrayImpl(T)(size_t n)
{
auto p = malloc(n * T.sizeof);
p || assert(0, "Not enough memory");
Thi
On 2/7/15 7:52 PM, tcak wrote:
One of the reasons why I use C functions is that I expect same behaviour
from D code what I would expect from C. I don't think it is a good idea
to make wrapper on top of them. Maybe you could say, "Hey, look, it just
makes safer, that's all", but, hmm there are so
On Sunday, 8 February 2015 at 04:02:52 UTC, H. S. Teoh wrote:
p || assert(0, "Not enough memory");
This is a truly strange way of writing it... why not:
assert(p !is null, "Not enough memory");
I think Andrei's version will remain in release builds, but yours
will be elided.
On Sat, Feb 07, 2015 at 06:19:19PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]
> private @system T[] mallocUninitializedArrayImpl(T)(size_t n)
> {
> auto p = malloc(n * T.sizeof);
> p || assert(0, "Not enough memory");
This is a truly strange way of writing it... why not:
On Saturday, 7 February 2015 at 23:50:55 UTC, Andrei Alexandrescu
wrote:
I was looking into ways to make core.stdc safer. That should be
relatively easy to do by defining a few wrappers. For example:
int setvbuf(FILE* stream, char* buf, int mode, size_t size);
is unsafe because there's no rel
On 2/7/15 5:26 PM, H. S. Teoh via Digitalmars-d wrote:
On Sun, Feb 08, 2015 at 12:39:39AM +, bearophile via Digitalmars-d wrote:
Andrei Alexandrescu:
Such wrappers would allow safe code to use more C stdlib primitives.
I'd also like a safer templated wrapper for calloc() and malloc() and
On Sunday, 8 February 2015 at 00:31:42 UTC, Mike wrote:
I'm elevating this from D.Learn [1] because I think it needs
some input from the language designers.
This code compiles and executes:
---
import std.stdio;
struct StaticRegister {
static private uint _v
On Sunday, 8 February 2015 at 00:51:21 UTC, Iain Buclaw wrote:
I don't think that's a viable option. It would lead to
completely
unintuitive behavior like the following:
---
bool isEqual(T)(T a, T b) { return a == b; }
int[0] a0;
int[1] a1;
assert(a0.ptr != a1.ptr);
assert(isEqual(a0.ptr, a1.
On Sun, Feb 08, 2015 at 12:39:39AM +, bearophile via Digitalmars-d wrote:
> Andrei Alexandrescu:
>
> >Such wrappers would allow safe code to use more C stdlib primitives.
>
> I'd also like a safer templated wrapper for calloc() and malloc() and
> similar.
[...]
You mean something like this?
On Sunday, 8 February 2015 at 01:17:02 UTC, Iain Buclaw wrote:
I will admit it is an odd special case. And definitely in the
land of
WAT if someone uses this in production code.
Fortunately it is very trivial to add a static analysis check for
this.
On 8 February 2015 at 00:51, Iain Buclaw wrote:
> On 7 February 2015 at 22:45, David Nadlinger via Digitalmars-d
> wrote:
>> On Saturday, 7 February 2015 at 15:04:52 UTC, Iain Buclaw wrote:
>>>
>>> a0.ptr == a1.ptr // false, enforced by compiler. Comparison not actually
>>> emitted.
>>
>>
>> I d
On 8 February 2015 at 00:51, Iain Buclaw wrote:
> On 7 February 2015 at 22:45, David Nadlinger via Digitalmars-d
> wrote:
>> On Saturday, 7 February 2015 at 15:04:52 UTC, Iain Buclaw wrote:
>>>
>>> a0.ptr == a1.ptr // false, enforced by compiler. Comparison not actually
>>> emitted.
>>
>>
>> I d
On 7 February 2015 at 22:45, David Nadlinger via Digitalmars-d
wrote:
> On Saturday, 7 February 2015 at 15:04:52 UTC, Iain Buclaw wrote:
>>
>> a0.ptr == a1.ptr // false, enforced by compiler. Comparison not actually
>> emitted.
>
>
> I don't think that's a viable option. It would lead to complete
Andrei Alexandrescu:
Such wrappers would allow safe code to use more C stdlib
primitives.
I'd also like a safer templated wrapper for calloc() and malloc()
and similar.
Bye,
bearophile
On 2/7/2015 11:43 PM, Jacob Carlborg wrote:
On 2015-02-04 23:00, Mike Parker wrote:
Then you specify a specific version of the library as a dependency,
rather than a version range.
No, this is not enough. The tool need to automatically track and lock
the whole dependency graph. Example:
Proj
I'm elevating this from D.Learn [1] because I think it needs some
input from the language designers.
This code compiles and executes:
---
import std.stdio;
struct StaticRegister {
static private uint _value;
@property static uint value() { return _value;
On Saturday, 7 February 2015 at 23:52:04 UTC, Andrei Alexandrescu
wrote:
On 2/7/15 3:46 PM, Paulo Pinto wrote:
Any attempt to assign anything outside 0..64 range to Size will
trigger an error, either at compile or run-time.
What would be the similarities and differences of this built-in
featu
On 2/7/15 3:46 PM, Paulo Pinto wrote:
Any attempt to assign anything outside 0..64 range to Size will
trigger an error, either at compile or run-time.
What would be the similarities and differences of this built-in feature
with traditional encapsulation using e.g. a C++ class? Thanks! -- Andre
I was looking into ways to make core.stdc safer. That should be
relatively easy to do by defining a few wrappers. For example:
int setvbuf(FILE* stream, char* buf, int mode, size_t size);
is unsafe because there's no relationship between buf and size. But this
is fine:
@trusted int setvbuf(
On Saturday, 7 February 2015 at 09:13:19 UTC, Ziad Hatahet wrote:
On Fri, Feb 6, 2015 at 12:08 AM, Paulo Pinto via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
For example no need to check if a variable is inside a
specific range, if
the type only allows that range.
Are you referring
Maybe someone should remove this from the Changelog?
http://dlang.org/changelog.html#partial-type
On Saturday, 7 February 2015 at 15:04:52 UTC, Iain Buclaw wrote:
a0.ptr == a1.ptr // false, enforced by compiler. Comparison
not actually
emitted.
I don't think that's a viable option. It would lead to completely
unintuitive behavior like the following:
---
bool isEqual(T)(T a, T b) { retu
auto var = (rvalue);
fails to compile if typeof(rvalue) has disabled the postblit. Why
isn't a move issued in this instance?
On Saturday, 7 February 2015 at 19:38:10 UTC, Marc Schütz wrote:
Hasn't there been a debate about a hypothetical
`opImplicitCast()`? The default would still be off, but you can
opt-in by defining said method.
How else would it be done? I am still confused as to what the
reasons behind not hav
On Saturday, 7 February 2015 at 19:38:10 UTC, Marc Schütz wrote:
On Saturday, 7 February 2015 at 05:27:39 UTC, Andrei
Alexandrescu wrote:
On 2/6/15 8:28 PM, Jonathan Marler wrote:
Do you know if D might support that later or if there's a
reason for not
supporting it?
It's deliberate followin
On Saturday, 7 February 2015 at 16:10:48 UTC, Andrei Alexandrescu
wrote:
On 2/7/15 8:02 AM, Daniel Murphy wrote:
"Andrei Alexandrescu" wrote in message
news:mb59ej$2j7s$1...@digitalmars.com...
> NRVO isn't required for correct semantics, as structs can
> be moved with
> bitcopy.
It is requi
On Saturday, 7 February 2015 at 12:10:45 UTC, Iain Buclaw wrote:
On 6 February 2015 at 23:42, David Nadlinger via Digitalmars-d
wrote:
On Friday, 6 February 2015 at 23:37:30 UTC, Iain Buclaw wrote:
Simple, you implement it by allocating no memory. :)
Let me put it a different way. Imagine
On Friday, 6 February 2015 at 23:21:50 UTC, weaselcat wrote:
On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic
wrote:
No, at least three of us, Steven, H.S. Teoh and myself have
confirmed that we've moved beyond requesting @trusted blocks.
We are no longer requesting them. We are re
On Saturday, 7 February 2015 at 16:10:48 UTC, Andrei Alexandrescu
wrote:
On 2/7/15 8:02 AM, Daniel Murphy wrote:
"Andrei Alexandrescu" wrote in message
news:mb59ej$2j7s$1...@digitalmars.com...
> NRVO isn't required for correct semantics, as structs can
> be moved with
> bitcopy.
It is requi
On Saturday, 7 February 2015 at 05:27:39 UTC, Andrei Alexandrescu
wrote:
On 2/6/15 8:28 PM, Jonathan Marler wrote:
Do you know if D might support that later or if there's a
reason for not
supporting it?
It's deliberate following the C++ experience. -- Andrei
Hasn't there been a debate about
On Saturday, 7 February 2015 at 14:36:19 UTC, Jacob Carlborg
wrote:
On 2015-02-05 05:43, Vladimir Panteleev wrote:
Is it a default if you can't change it? Or can it be changed?
It can be changed. It's the "mainSourceFile" field [1].
I don't see how this setting is at all relevant to the pro
On 2/7/15 8:02 AM, Daniel Murphy wrote:
"Andrei Alexandrescu" wrote in message
news:mb59ej$2j7s$1...@digitalmars.com...
> NRVO isn't required for correct semantics, as structs can be moved with
> bitcopy.
It is required for structs that disable postblit. -- Andrei
IIRC they only require tha
"Andrei Alexandrescu" wrote in message
news:mb59ej$2j7s$1...@digitalmars.com...
> NRVO isn't required for correct semantics, as structs can be moved with
> bitcopy.
It is required for structs that disable postblit. -- Andrei
IIRC they only require that no copies are made. They can still be
"Peter Alexander" wrote in message
news:gverkczeotvadwmdo...@forum.dlang.org...
Yes, you're right. I suppose what I mean is that it should be guaranteed
that returning a local Lvalue by value should always be moved to the
caller destination, rather than copied then destroyed.
S foo() {
S
On Saturday, 7 February 2015 at 15:02:43 UTC, Andrei Alexandrescu
wrote:
On 2/7/15 6:35 AM, Daniel Murphy wrote:
"Peter Alexander" wrote in message
news:uiqnamficseklfowm...@forum.dlang.org...
I'm writing a blog post about why we don't need rvalue
references in
D. It seems that we rely on NRV
On Saturday, 7 February 2015 at 14:46:55 UTC, Daniel Murphy wrote:
NRVO isn't required for correct semantics, as structs can be
moved with bitcopy.
Yes, you're right. I suppose what I mean is that it should be
guaranteed that returning a local Lvalue by value should always
be moved to the cal
On 2/7/15 6:35 AM, Daniel Murphy wrote:
"Peter Alexander" wrote in message
news:uiqnamficseklfowm...@forum.dlang.org...
I'm writing a blog post about why we don't need rvalue references in
D. It seems that we rely on NRVO being performed, not just as an
optimization, but for correct semantics
On 7 Feb 2015 12:50, "David Nadlinger via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> On Saturday, 7 February 2015 at 12:10:45 UTC, Iain Buclaw wrote:
>>
>> Some cod scenarios:
>> 1. Comparisons of == fold into 'false' (unless comparing to self)
>> 2. Comparisons of != fold into 'true
https://github.com/klickverbot/phobos/commit/db647f62cb5279ae42ad98665cd60cdcdb9b3dd5
Nice, thanks for this work. One good guideline here is to
almost always let generic code rely on deduction instead of
ascribing safety attributes to it.
Andrei
And making this work in functions that alrea
On 2/7/15 4:40 AM, David Nadlinger wrote:
On Friday, 6 February 2015 at 18:52:45 UTC, Andrei Alexandrescu wrote:
I think the problem is overstated. -- Andrei
I think there could hardly be a more persuasive argument that this
belief is wrong than Walter himself just having made the mistake seve
On 2015-02-05 15:11, Sönke Ludwig wrote:
There is a request to make this configurable and it's a rather trivial
addition. I just don't have the time to implement all feature requests
myself, which is basically why it is not implemented, yet.
Is the reason for putting it in the home directory t
And I'll add this:
Please do not turn the compiler into a inadequate verification
tool. The compiler should do what it can do well, but what it
cannot do it should not do at all and leave to an external
verification tool.
@trusted basically tells the compiler "this is beyond your
capability
"Peter Alexander" wrote in message
news:uiqnamficseklfowm...@forum.dlang.org...
I'm writing a blog post about why we don't need rvalue references in D. It
seems that we rely on NRVO being performed, not just as an optimization,
but for correct semantics (e.g. for objects without destructors o
On 2015-02-04 23:00, Mike Parker wrote:
Then you specify a specific version of the library as a dependency,
rather than a version range.
No, this is not enough. The tool need to automatically track and lock
the whole dependency graph. Example:
Project A:
"dependencies": {
"b": "1.0.0"
}
On 2/7/15 6:26 AM, Jacob Carlborg wrote:
On 2015-02-06 17:17, Andrei Alexandrescu wrote:
I see. Not surprising - some teams at Facebook also prefer phabricator
over github for reviews (others don't). I'm using both and phabricator
is somewhat - but not dramatically - better.
Any specifics you
On 2015-02-05 05:43, Vladimir Panteleev wrote:
Is it a default if you can't change it? Or can it be changed?
It can be changed. It's the "mainSourceFile" field [1].
It is not a question of preference, it is a question of the behavior
being incompatible with certain tools and workflows.
Sur
On 2015-02-06 17:17, Andrei Alexandrescu wrote:
I see. Not surprising - some teams at Facebook also prefer phabricator
over github for reviews (others don't). I'm using both and phabricator
is somewhat - but not dramatically - better.
Any specifics you can point out where phabricator is better
I'm writing a blog post about why we don't need rvalue references
in D. It seems that we rely on NRVO being performed, not just as
an optimization, but for correct semantics (e.g. for objects
without destructors or postblits). This doesn't appear to be
documented anywhere.
Is it meant to be p
On Saturday, 7 February 2015 at 12:40:26 UTC, David Nadlinger
wrote:
Neither of those issues would have been prevented by your new
guidelines; the code in question is already written in that
way. Quite to the contrary, consequent application of minimal
@trusted blocks or even the workaround you
On 2015-02-07 at 13:21, Iain Buclaw via Digitalmars-d wrote:
foo(&p.data)// fine, ubyte*
This is OK - gets passed as ubyte*
bar(p.data[i]) // fine, ubyte (or memory violation)
This is OK - gets passed as ubyte - though will throw arrayBounds
error unless -noboundschecks.
On Saturday, 7 February 2015 at 06:23:43 UTC, ketmar wrote:
On Fri, 06 Feb 2015 18:48:16 +, deadalnix wrote:
Well you are talking for talking, we are waiting on your
awesome PRs.
easy deal. and i'm waiting for Andrei and Walter
preapprovement. i'm not
interested in writing code for noth
On Saturday, 7 February 2015 at 12:10:45 UTC, Iain Buclaw wrote:
Some cod scenarios:
1. Comparisons of == fold into 'false' (unless comparing to
self)
2. Comparisons of != fold into 'true' (unless comparing to
self)
3. Conversion to dynamic arrays is { .length=0, .ptr=&arr0 }
What does "ar
On Friday, 6 February 2015 at 18:52:45 UTC, Andrei Alexandrescu
wrote:
I think the problem is overstated. -- Andrei
I think there could hardly be a more persuasive argument that
this belief is wrong than Walter himself just having made the
mistake several times, and not even immediately reali
On Saturday, 7 February 2015 at 11:29:51 UTC, Jacob Carlborg
wrote:
On 2015-02-04 21:55, Walter Bright wrote:
No need to reinvent this:
https://github.com/D-Programming-Language/phobos/blob/master/std/file.d
line 194
Just for the record, you can get a link to the exact line by
clickin
On Friday, 6 February 2015 at 23:25:02 UTC, Walter Bright wrote:
On 2/6/2015 3:02 PM, Zach the Mystic wrote:
This solution appeals to me greatly. It pinpoints precisely
where unsafe code
can generate; it catches unintended safety violations in all
@trusted code
outside @system blocks, as reques
On 7 February 2015 at 10:56, FG via Digitalmars-d
wrote:
> On 2015-02-07 at 00:42, David Nadlinger wrote:
>>
>> Imagine you have this in your program:
>>
>> ---
>> void foo() {
>>int[0] a0;
>>int[0] a1;
>>...
>>int[0] a99;
>>
>>// Do something with them.
>> }
>> ---
>>
>> How d
On Saturday, 7 February 2015 at 11:32:41 UTC, Steven
Schveighoffer wrote:
The idea is that @trusted code still has to be reviewed for
memory issues, but is mechanically checked for most of the
function for obvious @safe violations. It limits to a degree
the scrutiny one must apply to the @trust
On 2/6/15 8:43 PM, Andrei Alexandrescu wrote:
On 2/6/15 3:21 PM, weaselcat wrote:
On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic wrote:
No, at least three of us, Steven, H.S. Teoh and myself have confirmed
that we've moved beyond requesting @trusted blocks. We are no longer
reques
On 6 February 2015 at 23:42, David Nadlinger via Digitalmars-d
wrote:
> On Friday, 6 February 2015 at 23:37:30 UTC, Iain Buclaw wrote:
>>
>> Simple, you implement it by allocating no memory. :)
>
>
> Let me put it a different way. Imagine you have this in your program:
>
> ---
> void foo() {
> i
On Saturday, 7 February 2015 at 06:20:16 UTC, Walter Bright wrote:
On 2/6/2015 9:49 PM, Vladimir Panteleev wrote:
On Friday, 6 February 2015 at 21:08:21 UTC, Walter Bright
wrote:
1. exceptions are not for debugging the logic of your program
2. do not use exceptions to recover from logic bugs in
On 2/6/15 5:19 PM, Meta wrote:
On Friday, 6 February 2015 at 20:13:18 UTC, Steven Schveighoffer wrote:
In the proposal, @trusted code is actually considered the same as
@safe, but allows @system escapes.
That seems like a good idea and in the spirit of what the goal is.
However, won't it be a
On 2/6/15 4:36 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
On Friday, 6 February 2015 at 20:13:18 UTC, Steven Schveighoffer wrote:
In the proposal, @trusted code is actually considered the same as
@safe, but allows @system escapes.
But that can't work:
@trusted_is_safe {
auto tmp =
On 2015-02-04 21:55, Walter Bright wrote:
No need to reinvent this:
https://github.com/D-Programming-Language/phobos/blob/master/std/file.d
line 194
Just for the record, you can get a link to the exact line by clicking on
the line number in the left margin and the copying the link from
On 2015-02-07 at 00:42, David Nadlinger wrote:
Imagine you have this in your program:
---
void foo() {
int[0] a0;
int[0] a1;
...
int[0] a99;
// Do something with them.
}
---
How do you choose the addresses for a0 through a99 so that they are distinct,
but you don't end up alloc
On Saturday, 7 February 2015 at 10:02:23 UTC, ponce wrote:
If I understand correctly, your rule o be a trusted function is:
"Unable to create a memory corrutpion whatever the arguments".
But here:
- dest or src could be the null slice
- the assert would go away in release
So I though this examp
On Thursday, 5 February 2015 at 23:39:39 UTC, Walter Bright wrote:
The solution is to regard @trusted as a means of encapsulating
unsafe operations, not escaping them. Encapsulating them means
that the interface from the @trusted code is such that it is
usable from safe code without having to m
On Fri, Feb 6, 2015 at 12:08 AM, Paulo Pinto via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> For example no need to check if a variable is inside a specific range, if
> the type only allows that range.
>
>
>
Are you referring specifically to Ada here? Otherwise, how would ML-based
langua
On Saturday, 7 February 2015 at 00:31:41 UTC, H. S. Teoh wrote:
This does not take into the account the fact that a @trusted
function
may call other, non-@trusted, functions. When one of those other
functions changes, the @trusted function necessarily needs to be
reviewed again.
However, under
71 matches
Mail list logo
