So I've been working on Bug 8859 (really on Illumos which is the fork of
the source that remained open after Oracle bought Sun, though for X86,
they're still similar enough that this should for now work on either).
To date, I've been doing my work with GDC (DMD was generating objects with
some inv
http:///dynamic.dlang.ru/Files/2014/Dlang_logos.png
Hi folks,
I'm unable to debug binaries built with dmd 2.065. The platform is
x86-64 Ubuntu 14.04. This is gdb 7.7.
If I have a simple program:
nodebug.d:
void main() {
int i;
i = 3;
}
dmd -g nodebug.d
jlquinn@wyvern:~/d$ gdb nodebug
GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
Copyright (C) 201
On 19/06/14 15:59, Timon Gehr wrote:
On 06/18/2014 09:54 PM, Meta wrote:
...
This could be a bad thing. It makes it pretty enticing to use contracts
as input verification instead of logic verification.
The following is doable as well with a standard range analysis:
byte foo(immutable int x){
On 6/19/2014 3:27 PM, Andrej Mitrovic via Digitalmars-d wrote:
I claimed a bounty recently, and I just wanted to say thanks to Andrei and his
company for backing the bounty.
Glad to see the bounties working! Thank you, FB!
On 6/19/2014 12:59 PM, Joakim wrote:
Admittedly his concerns are unclear, but his problem is with the backend, not
the frontend, which he already said he likes better now that it's
boost-licensed. He claims that the proprietary backend scares potential
contributors away and that it should be "sp
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 w
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 ...
str
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 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 Thursday, 19 June 2014 at 21:57:03 UTC, FreeSlave wrote:
Is there any good icon for D source files? Now .d files look
like plain text files. I changed mime on my Debian to use dlang
site logo for .d files, but it looks weird among with others
(C, C++, etc.)
I'm not artist, but I see there
On Thu, Jun 19, 2014 at 03:23:33PM -0700, H. S. Teoh via Digitalmars-d wrote:
[...]
> Unfortunately, it appears that opDispatch has become too complex to be
> inlined, so now gdc is unable to simplify it to a series of nested
> if's. :-(
[...]
Surprisingly, if we just stick .exists in there uncon
I claimed a bounty recently, and I just wanted to say thanks to Andrei and
his company for backing the bounty.
I won't be able to take any future bounties from Facebook due to internal
competition policies, but that's ok as I'm now a paid programmer anyway. :)
It was fun to win something while co
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 ha
On Thu, Jun 19, 2014 at 02:37:33PM -0700, H. S. Teoh via Digitalmars-d wrote:
[...]
> Here, I've made it so that the .exists field is only present if the
> wrapped type T doesn't have a null value that can serve as an
> existence marker.
>
> I'm not sure if this is the right thing to do 100% of th
On Thursday, 19 June 2014 at 21:57:03 UTC, FreeSlave wrote:
Is there any good icon for D source files? Now .d files look
like plain text files. I changed mime on my Debian to use dlang
site logo for .d files, but it looks weird among with others
(C, C++, etc.)
I'm not artist, but I see there
On 06/19/2014 11:28 PM, "Ola Fosheim Grøstad"
" wrote:
But we aren't talking machine language, we are talking D.
This part is spot on.
On Thursday, 19 June 2014 at 21:34:07 UTC, Andrei Alexandrescu
wrote:
On 6/18/14, 10:39 AM, deadalnix wrote:
Use a maybe monad :
Maybe(obj).memeber.nested.val
Yah, I keep on thinking we should explore the maybe monad more
thoroughly as a library in D. -- Andrei
The other night for fun I tri
Is there any good icon for D source files? Now .d files look like
plain text files. I changed mime on my Debian to use dlang site
logo for .d files, but it looks weird among with others (C, C++,
etc.)
I'm not artist, but I see there are some on this forum. Maybe
someone would make such icon.
On 06/19/2014 10:39 PM, "Ola Fosheim Grøstad"
" wrote:
On Thursday, 19 June 2014 at 20:26:27 UTC, Timon Gehr wrote:
...
No, your line of reasoning is flawed. The amount of resources is not a
constant. You must prove that memory safety holds for
I have not set out to prove anything,
This is a
On Thu, Jun 19, 2014 at 05:05:51PM -0400, Etienne via Digitalmars-d wrote:
> On 2014-06-19 4:51 PM, H. S. Teoh via Digitalmars-d wrote:
> >This assumes that t.init is not a possible valid field value. But in
> >that case, there's no need to remap it, you just check for t.init
> >instead. For pointe
On 6/18/14, 10:39 AM, deadalnix wrote:
Use a maybe monad :
Maybe(obj).memeber.nested.val
Yah, I keep on thinking we should explore the maybe monad more
thoroughly as a library in D. -- Andrei
On Thursday, 19 June 2014 at 20:47:16 UTC, H. S. Teoh via
Digitalmars-d wrote:
programs!). So the only remaining approach is to consider all
possible
programs. Which means you have to implement exhaustive state
space
search. Which is impractical for the reasons I stated.
No. Is a program comp
On 2014-06-19 5:05 PM, Etienne wrote:
: __traits(getMember, t, field), (t is null) ? true : false);
(t is null || fail) ? true : false
On 2014-06-19 4:51 PM, H. S. Teoh via Digitalmars-d wrote:
This assumes that t.init is not a possible valid field value. But in
that case, there's no need to remap it, you just check for t.init
instead. For pointers, where .init is null, this isn't a problem, but
for things like int, where 0 is p
On Thu, Jun 19, 2014 at 01:51:17PM -0700, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Jun 19, 2014 at 04:29:12PM -0400, Etienne via Digitalmars-d wrote:
[...]
> > meh, this works:
> >
> >
> > writeln(currAssignment.safeDeref.typeInfo.ident.or("meh"));
> >
> > ..
> > static struct SafeDeref
On Thu, Jun 19, 2014 at 04:29:12PM -0400, Etienne via Digitalmars-d wrote:
> On 2014-06-19 3:11 PM, H. S. Teoh via Digitalmars-d wrote:
> >
> > safeDeref(obj).subobj.prop.field.failsafe!val(defaultVal)
> >
> >where the last element is passed as an alias to the failsafe template,
> >which then d
On Thu, Jun 19, 2014 at 08:31:53PM +, via Digitalmars-d wrote:
> On Thursday, 19 June 2014 at 19:37:32 UTC, H. S. Teoh via Digitalmars-d
> wrote:
> >But the non-solvability of the halting problem means that there is no
> >algorithm that can compress every possible program.
>
> Even if true, pr
On 06/19/2014 09:06 PM, "Ola Fosheim Grøstad"
" wrote:
On Thursday, 19 June 2014 at 18:25:00 UTC, Tobias Pankrath wrote:
It's not. Since the resources to verify a property are limited, too.
If I need to enumerate all possible program states, there will always
exists a program that can run on my
On Thursday, 19 June 2014 at 20:26:27 UTC, Timon Gehr wrote:
I assume you mean @safe <===> memory safety.
I mean that the best route in general is: @safe => memory safe
features on the local level (trivial) => "strength reduction"
into memory safe use of memory unsafe features (trivial).
No
On Thursday, 19 June 2014 at 19:37:32 UTC, H. S. Teoh via
Digitalmars-d wrote:
But the non-solvability of the halting problem means that there
is no
algorithm that can compress every possible program.
Even if true, programmers don't write every possible program when
they try to write @safe co
+1
I have always wondered why `inout` is limited to const when
problem is almost identical with all other restrictive attributes.
On 2014-06-19 3:11 PM, H. S. Teoh via Digitalmars-d wrote:
safeDeref(obj).subobj.prop.field.failsafe!val(defaultVal)
where the last element is passed as an alias to the failsafe template,
which then does the .init-replacement magic. It looks a lot uglier,
though. :-(
T
meh, this wo
On 06/19/2014 06:06 AM, "Ola Fosheim Grøstad"
" wrote:
...
In the real world you work with typical programs that run on finite
resources guided by heuristics. There is no proof that you cannot have
@safe.
I assume you mean @safe <===> memory safety.
So leave that line of arguing. It is fundam
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.
On Thursday, 19 June 2014 at 19:12:53 UTC, Ola Fosheim Grøstad
wrote:
You are being silly. You either discuss computability or you
discuss complexity. Please don't mix the two topics.
Do you have something to contribute to THIS discussion, or ill
you continue to bring irrelevant topic in ?
On Thu, Jun 19, 2014 at 07:22:22PM +, Wyatt via Digitalmars-d wrote:
> On Thursday, 19 June 2014 at 05:35:06 UTC, Nick Sabalausky wrote:
> >
> >certainly be nice. But all the data's there at once, so no need for
> >constant fast-fowarding and rewindi...oh wait, that's right,
> >debuggers can't
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
callback
On Thursday, 19 June 2014 at 18:10:57 UTC, Walter Bright wrote:
On 6/19/2014 4:12 AM, Artur Skawina via Digitalmars-d wrote:
On 06/18/14 18:42, Dicebot via Digitalmars-d wrote:
On Wednesday, 18 June 2014 at 11:09:14 UTC, Artur Skawina via
Digitalmars-d wrote:
The number of potential contributo
On Thursday, 19 June 2014 at 19:22:23 UTC, Wyatt wrote:
On Thursday, 19 June 2014 at 05:35:06 UTC, Nick Sabalausky
wrote:
certainly be nice. But all the data's there at once, so no
need for constant fast-fowarding and rewindi...oh wait, that's
right, debuggers can't rewind either. ;)
Oh?
On 06/19/2014 06:58 PM, Yota wrote:
Won't opDispatch here destroy any hope for statement completion in the
future? I feel like D already has little hope for such tooling
features, but this puts the final nail in the coffin.
auto opDispatch(string field)()
if(is(typeof(__traits(getMember,
On Thu, Jun 19, 2014 at 07:12:52PM +, via Digitalmars-d wrote:
> On Thursday, 19 June 2014 at 18:50:27 UTC, H. S. Teoh via Digitalmars-d
> wrote:
> >Exactly. Just because something is *finite*, doesn't necessarily
> >mean it's practical. Anything that requires enumeration of all
> >possible s
On Thursday, 19 June 2014 at 05:35:06 UTC, Nick Sabalausky wrote:
certainly be nice. But all the data's there at once, so no
need for constant fast-fowarding and rewindi...oh wait, that's
right, debuggers can't rewind either. ;)
Oh?
https://www.gnu.org/software/gdb/news/reversible.html
htt
On Thursday, 19 June 2014 at 18:50:27 UTC, H. S. Teoh via
Digitalmars-d wrote:
Exactly. Just because something is *finite*, doesn't
necessarily mean
it's practical. Anything that requires enumeration of all
possible
states is impractical, because it has an exponential worst case
bound,
which
On Thu, Jun 19, 2014 at 04:40:22PM +0100, Nick Treleaven via Digitalmars-d
wrote:
> On 19/06/2014 16:04, H. S. Teoh via Digitalmars-d wrote:
> >we really should call it something else. "failsafe" sounds a bit too
> >generic. What about "safeDeref" or just "deref"?
>
> fallback? It could have an
On Thursday, 19 June 2014 at 18:25:00 UTC, Tobias Pankrath wrote:
It's not. Since the resources to verify a property are limited,
too.
If I need to enumerate all possible program states, there will
always exists a program that can run on my box but will not be
verifiable on it (since I lack t
On Thu, Jun 19, 2014 at 06:24:59PM +, Tobias Pankrath via Digitalmars-d
wrote:
> On Thursday, 19 June 2014 at 04:06:51 UTC, Ola Fosheim Grøstad wrote:
> >On Wednesday, 18 June 2014 at 21:57:40 UTC, deadalnix wrote:
> >>Granted infinite resources. Good, now that we ruled that thing out,
> >>can
In this case auto completion could work flawless because of
alias this t;
At least for cases where even a frontend based tool has a hard time, we
could introduce a ddoc section for this, if there really is a need.
/**
* Dispatch method call.
* Completion: LIKE t
*/
auto opDispatch(string
On Thursday, 19 June 2014 at 04:06:51 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 18 June 2014 at 21:57:40 UTC, deadalnix wrote:
Granted infinite resources. Good, now that we ruled that thing
out, can we talk about the subject, or do we need to continue
talking about imaginary things ?
No, f
In this case, the signature constraint on opDispatch could be
used for
auto completion:
auto opDispatch(string field)()
if (is(typeof(__traits(getMember, t, field
...
From the signature constraint, it should be obvious that
"field" must be
a
On 6/19/2014 4:12 AM, Artur Skawina via Digitalmars-d wrote:
On 06/18/14 18:42, Dicebot via Digitalmars-d wrote:
On Wednesday, 18 June 2014 at 11:09:14 UTC, Artur Skawina via Digitalmars-d
wrote:
The number of potential contributors is
already low enough, and the fuzzy licensing situation driv
bump
On 6/19/2014 10:44 AM, safety0ff wrote:
A year and a half ago Andrej Mitrovic created a DMD pull ([1]) which implements
dmd adding a prefix string containing the failing assertion to the assertion
error's "msg" field.
It appears to do more than that, such as always adding the assertion expressi
On a related topic:
Feature like this is extremely convenient for unit tests. However
using assertions in unit test blocks does not fit well with any
custom test runner that does not immediately terminate the
application (because AssertionError is an Error).
I'd personally love some way to g
A year and a half ago Andrej Mitrovic created a DMD pull ([1])
which implements dmd adding a prefix string containing the
failing assertion to the assertion error's "msg" field.
Unfortunately it triggered code generation bugs, issues #12852 &
#12855, which have recently been fixed ([2] & [3].)
On Thu, Jun 19, 2014 at 05:26:31PM +, Tofu Ninja via Digitalmars-d wrote:
> On Thursday, 19 June 2014 at 16:58:03 UTC, Yota wrote:
> >Won't opDispatch here destroy any hope for statement completion in
> >the future? I feel like D already has little hope for such tooling
> >features, but this p
On Thursday, 19 June 2014 at 13:52:12 UTC, Kagamin wrote:
On Wednesday, 18 June 2014 at 19:08:17 UTC, c0de517e wrote:
Exactly. When I write that engineers have to understand how
market works it's not that I don't understand what's
technically good and bad, but that's not how things become
succ
On Thursday, 19 June 2014 at 16:58:03 UTC, Yota wrote:
Won't opDispatch here destroy any hope for statement completion
in the future? I feel like D already has little hope for such
tooling features, but this puts the final nail in the coffin.
Yeah D is already really bad for auto completi
On Wednesday, 18 June 2014 at 19:37:42 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Wed, Jun 18, 2014 at 07:04:33PM +, via Digitalmars-d
wrote:
On Wednesday, 18 June 2014 at 17:56:46 UTC, Mattcoder wrote:
>On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
>>it would be a little more
On Thu, Jun 19, 2014 at 10:35:59AM +0200, Timon Gehr via Digitalmars-d wrote:
> On 06/18/2014 09:36 PM, H. S. Teoh via Digitalmars-d wrote:
> >Here's a first stab at a library solution:
> >
> > /**
> > * Simple-minded implementation of a Maybe monad.
> > *
>
> Nitpick: Please do not
On Thursday, 19 June 2014 at 15:40:29 UTC, Nick Treleaven wrote:
fallback? It could have an optional argument to override init.
I like that, makes it obvious what it does. The optional override
is also very good and stays in line with the idea of a fallback.
On 19/06/2014 16:04, H. S. Teoh via Digitalmars-d wrote:
we really should call it
something else. "failsafe" sounds a bit too generic. What about
"safeDeref" or just "deref"?
fallback? It could have an optional argument to override init.
I've been thinking about the name. I realize that it's not a true monad
in the Haskell sense, even though the implementation *was* inspired by
deadalnix's mentioning of the Maybe monad, so we really should call it
something else. "failsafe" sounds a bit too generic. What about
"safeDeref" or just
On Wed, 18 Jun 2014 01:40:47 -0400, Sebastian Unger
wrote:
On Wednesday, 18 June 2014 at 04:38:25 UTC, Meta wrote:
On Wednesday, 18 June 2014 at 01:31:33 UTC, Sebastian Unger wrote:
There's no head const in D, but you can emulate it. This is a *very*
basic example that you can expand upon.
On Thu, Jun 19, 2014 at 09:15:47AM -0400, Etienne via Digitalmars-d wrote:
> On 2014-06-19 7:31 AM, Nick Treleaven wrote:
> >Perhaps Maybe could implement opCast!bool, then we could do:
> >
> >if (auto v = ...)
>
> That would be amazing, but maybe is used in haskell for a different
> purpose, so f
On Thursday, 19 June 2014 at 10:10:30 UTC, Jacob Carlborg wrote:
On 2014-06-18 17:46, Kapps wrote:
C# is getting the same syntax, and I remember there being some
discussion about it here. It's somewhat useful I suppose,
though I think
it's made significantly more useful in C# with 'a ?? b' (a
On Wednesday, 18 June 2014 at 19:08:17 UTC, c0de517e wrote:
Exactly. When I write that engineers have to understand how
market works it's not that I don't understand what's
technically good and bad, but that's not how things become
successful. And there's nothing wrong with the fact that soft
On 2014-06-19 7:31 AM, Nick Treleaven wrote:
Perhaps Maybe could implement opCast!bool, then we could do:
if (auto v = ...)
That would be amazing, but maybe is used in haskell for a different
purpose, so failsafe could be a more appropriate name I think:
if (auto k = tree.failsafe.left &&
On Thursday, 19 June 2014 at 12:00:01 UTC, Tomer Filiba wrote:
That requires me having the names in scope, etc. I want to be
able to use the function object, just like I could do if it
weren't a method.
-tomer
class C
{
void methodOfC(int x) { writeln(x); };
}
void main()
{
auto c =
That requires me having the names in scope, etc. I want to be
able to use the function object, just like I could do if it
weren't a method.
-tomer
On Thursday, 19 June 2014 at 09:22:09 UTC, Tobias Pankrath wrote:
On Thursday, 19 June 2014 at 09:16:07 UTC, Tomer Filiba wrote:
I tried `F(in
On 18/06/2014 21:20, "Ola Fosheim Grøstad"
" wrote:
On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
writeln(obj.member?.nested?.val);
Optional chaining in swift is meant to be used more like this:
if let v = ptr?.attr?.getobj?()?.attr? {
writeln(v)
} else {
writeln("oops?!"
19-Jun-2014 11:36, Timothee Cour via Digitalmars-d пишет:
On Wed, Jun 18, 2014 at 12:37 PM, Dmitry Olshansky via Digitalmars-d
mailto:digitalmars-d@puremagic.com>> wrote:
18-Jun-2014 21:38, Timothee Cour via Digitalmars-d пишет:
I made a simple modification to std.regex to allow an
On 06/18/14 18:42, Dicebot via Digitalmars-d wrote:
> On Wednesday, 18 June 2014 at 11:09:14 UTC, Artur Skawina via Digitalmars-d
> wrote:
>> The number of potential contributors is
>> already low enough, and the fuzzy licensing situation drives away the
>> most valuable ones (since those will oft
On Thursday, 19 June 2014 at 05:35:06 UTC, Nick Sabalausky wrote:
That's why I inadvertently learned to love printf debugging. I
get to see the whole "chart" at one. Granted, it's in a bit of
a "The Matrix"-style "only comprehensible if you know what
you're looking at" kind of way. Actual GUI g
Etienne:
Yes, it's more like a failsafe than a maybe.
failsafe(c).left.right ...
I suggest to not call it Maybe/maybe to not confuse it with the
Haskell ones.
Bye,
bearophile
Nitpick: Please do not call it a 'Maybe monad'.
It is not a monad: It's neither a functor not does it have a μ operator.
(This could be fixed though.) Furthermore, opDispatch does not behave
analogously to a (restricted) monadic bind operator
Yes, it's more like a failsafe than a maybe. failsafe
On 2014-06-18 17:46, Kapps wrote:
C# is getting the same syntax, and I remember there being some
discussion about it here. It's somewhat useful I suppose, though I think
it's made significantly more useful in C# with 'a ?? b' (a if a is not
null, else b).
And "a ??= b", assigne "b" to "a", onl
On 2014-06-18 08:35, Daniel Murphy wrote:
I think D used to have this in the form of the 'final' storage class for
variables. I'm not sure why we got rid of it.
If I recall correctly it was also how "const" worked in D1.
--
/Jacob Carlborg
On Thursday, 19 June 2014 at 09:16:07 UTC, Tomer Filiba wrote:
I tried `F(inst, args)` or `inst.F(args)` but they don't
work... what I need is the inverse of UFCS (e.g.,
`func(inst,1,2,3) ==> inst.func(1,2,3)`)
Is there any way to overcome this?
Thanks,
-tomer
Did you try: mixin("inst.f(
Is there a way to explicitly pass `this` instance to a method?
Consider the following example:
---
class Foo {
void f(int a) {}
}
struct Caller(alias F) {
mixin(__traits(parent, F).stringof ~ " inst;");
auto call(ParameterTypeTuple!F args) {
return F(args);
}
}
voi
On Thursday, 19 June 2014 at 08:50:55 UTC, Chris Nicholson-Sauls
wrote:
invariant
{
assert(someB !is null);
}
Obviously that should be assert(_b !is null).. I need more
caffeine before posting.
Ok, I must be missing something...
Just to make sure I'm understanding the OP: he wants to create
two classes, A and B, such that each instance of A must be given
a B to cling to, and which cannot be reassigned? In what way is
the following insufficient?
class B {/*...*/}
class A
{
th
On Thursday, 19 June 2014 at 03:10:50 UTC, logicchains wrote:
Somebody should blog on this or put it on the front page or
something; how many other languages allow a cost-free maybe
monad to be implemented in library code?
I agree. This is supercool!
On 06/18/2014 09:36 PM, H. S. Teoh via Digitalmars-d wrote:
Here's a first stab at a library solution:
/**
* Simple-minded implementation of a Maybe monad.
*
Nitpick: Please do not call it a 'Maybe monad'.
It is not a monad: It's neither a functor not does it have a μ
H. S. Teoh:
This is a different instance of the same problem as above,
isn't it?
If Bound has access to compiler knowledge about value ranges,
then it
would be able to statically reject out-of-range values.
Yes, with the latest patch by Kenji it's thankfully an instance
of the same problem
void main() {
import std.bigint;
BigInt[] arr = [10, 20];
import std.numeric;
alias I10 = Bound!(int, 0, 10);
I10[] arr = [8, 6, 20];
}
In the meantime Kenji delivers, those BigInt array literals are
possible with this patch:
https://github.com/D-Programming-Language/dmd/p
On 06/18/2014 09:54 PM, Meta wrote:
...
This could be a bad thing. It makes it pretty enticing to use contracts
as input verification instead of logic verification.
The following is doable as well with a standard range analysis:
byte foo(immutable int x){
if(xbyte.max)
throw new I
On Wed, Jun 18, 2014 at 12:37 PM, Dmitry Olshansky via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> 18-Jun-2014 21:38, Timothee Cour via Digitalmars-d пишет:
>
> I made a simple modification to std.regex to allow an option to prefix
>> match a regex.
>> Formally, if L(R) is the language
88 matches
Mail list logo
