Am Thu, 19 Jun 2014 12:59:00 -0700
schrieb Walter Bright newshou...@digitalmars.com:
With nothrow and @nogc annotations, we've been motivated to add these
annotations to C system API functions, because obviously such functions
aren't
going to throw D exceptions or call the D garbage
On Tuesday, 8 July 2014 at 17:16:27 UTC, Marco Leise wrote:
2) Druntime must adapt to the system's C compiler's ABI.
(by the use of libunwind)
Yes, longjmp() could happen in a callback and may be expected to
unwind the stack (depending on the dev environment).
On Sunday, 22 June 2014 at 08:43:20 UTC, Rainer Schuetze wrote:
On 22.06.2014 02:23, Andrei Alexandrescu wrote:
Callbacks passed into OS/clib functions are never supposed to
throw so
we must annotate them all with nothrow. C functions are never
designed
under the assumption callbacks may
On Sunday, 22 June 2014 at 00:23:06 UTC, Andrei Alexandrescu
wrote:
On 6/20/14, 3:14 AM, Rainer Schuetze wrote:
We either have to be more conservative with annotating OS
functions or
relax the guarantees of nothrow or @nogc. Both alternatives
are not very
compelling.
Callbacks passed into
On 22.06.2014 02:23, Andrei Alexandrescu wrote:
On 6/20/14, 3:14 AM, Rainer Schuetze wrote:
We either have to be more conservative with annotating OS functions or
relax the guarantees of nothrow or @nogc. Both alternatives are not very
compelling.
Callbacks passed into OS/clib functions are
On Thursday, 19 June 2014 at 23:41:25 UTC, H. S. Teoh via
Digitalmars-d wrote:
Pretty soon, we need an attribute algebra to express these
complicated
relationships.
It would be nice to have a solution that can handle all of
these cases
without exploding complexity in the syntax.
Here's one
H. S. Teoh:
Pretty soon, we need an attribute algebra to express these
complicated relationships.
I think problems come from refusing to have formalized features
in D. Having an attribute algebra is the lesser problem. Having
formalized features causes problems, but no having them
22-Jun-2014 14:39, bearophile пишет:
H. S. Teoh:
Pretty soon, we need an attribute algebra to express these complicated
relationships.
I think problems come from refusing to have formalized features in D.
Having an attribute algebra is the lesser problem. Having formalized
features causes
On 6/20/14, 3:14 AM, Rainer Schuetze wrote:
We either have to be more conservative with annotating OS functions or
relax the guarantees of nothrow or @nogc. Both alternatives are not very
compelling.
Callbacks passed into OS/clib functions are never supposed to throw so
we must annotate them
On 19.06.2014 21:59, Walter Bright wrote:
With nothrow and @nogc annotations, we've been motivated to add these
annotations to C system API functions, because obviously such functions
aren't going to throw D exceptions or call the D garbage collector.
But this exposed a problem - functions
On Thursday, 19 June 2014 at 19:58:58 UTC, Walter Bright wrote:
snip
The callback function, being supplied by the D programmer, may
throw and may call the garbage collector. By requiring the
callback function to be also nothrow @nogc, this is an
unreasonable requirement besides breaking most
On Friday, 20 June 2014 at 11:07:48 UTC, Paolo Invernizzi wrote:
On Thursday, 19 June 2014 at 19:58:58 UTC, Walter Bright wrote:
snip
The callback function, being supplied by the D programmer, may
throw and may call the garbage collector. By requiring the
callback function to be also nothrow
On 06/20/14 01:39, H. S. Teoh via Digitalmars-d wrote:
On Fri, Jun 20, 2014 at 12:36:53AM +0200, Timon Gehr via Digitalmars-d wrote:
On 06/19/2014 10:29 PM, Dicebot wrote:
I have always wondered why `inout` is limited to const when problem
is almost identical with all other restrictive
With nothrow and @nogc annotations, we've been motivated to add these
annotations to C system API functions, because obviously such functions aren't
going to throw D exceptions or call the D garbage collector.
But this exposed a problem - functions like C's qsort() take a pointer to a
On Thu, Jun 19, 2014 at 12:59:00PM -0700, Walter Bright via Digitalmars-d wrote:
With nothrow and @nogc annotations, we've been motivated to add these
annotations to C system API functions, because obviously such
functions aren't going to throw D exceptions or call the D garbage
collector.
+1
I have always wondered why `inout` is limited to const when
problem is almost identical with all other restrictive attributes.
On Thursday, 19 June 2014 at 20:29:42 UTC, Dicebot wrote:
+1
I have always wondered why `inout` is limited to const when
problem is almost identical with all other restrictive
attributes.
I think the most common function this kind of thing could be
useful for would be opApply functions. I
On Thu, Jun 19, 2014 at 10:22:32PM +, w0rp via Digitalmars-d wrote:
On Thursday, 19 June 2014 at 20:29:42 UTC, Dicebot wrote:
+1
I have always wondered why `inout` is limited to const when problem
is almost identical with all other restrictive attributes.
I think the most common
On 06/19/2014 10:29 PM, Dicebot wrote:
+1
I have always wondered why `inout` is limited to const when problem is
almost identical with all other restrictive attributes.
I have furthermore always wondered why there can always only be one
`inout' wildcard in scope. This is not the best existing
On Thursday, 19 June 2014 at 22:22:33 UTC, w0rp wrote:
I haven't yet figured out a good way to make opApply
implementations get all of the nice qualifiers without writing
a bunch of overloads.
I don't know how practical this is, but since attributes are
inferred for templated methods ...
On Fri, Jun 20, 2014 at 12:36:53AM +0200, Timon Gehr via Digitalmars-d wrote:
On 06/19/2014 10:29 PM, Dicebot wrote:
+1
I have always wondered why `inout` is limited to const when problem
is almost identical with all other restrictive attributes.
I have furthermore always wondered why there
21 matches
Mail list logo
