Thread overview | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
October 31, 2010 [phobos] A few minor features | ||||
---|---|---|---|---|
| ||||
I want to add a few minor pieces of functionality to Phobos, but would like some feedback on: 1. Whether they're necessary or whether some more general feature will eventually solve the same problem. 2. What module they belong in. 3. Better names. I want very terse names for all of these because their nature is to work around issues (not bugs, just design decisions that get in the way in a few specific cases) with builtin language features that are very terse. The functionality is: 1. Static array literals that are guaranteed to avoid heap allocations: /** Creates a static array literal, avoiding the heap allocation that results from a regular array literal. */ CommonType!(T)[T.length] staticArray(T...)(T elems) if(is(CommonType!(T))) { typeof(return) ret = void; foreach(i, Unused; T) { ret[i] = elems[i]; } return ret; } 2. A function that allows the address of a nested function to be taken w/o a heap allocation. /** Allows the address of a nested function to be (unsafely) taken without resulting in a heap allocation. */ T scopeAddress(T)(scope T val) { return val; } Usage: void fun() { void nested() {} auto addr = scopeAddress(&nested); } 3. An alwaysAssert() function that stays on in release mode but is otherwise equivalent to assert(). I had been using enforce() for this, but I don't like that anymore because it throws Exception, not AssertError by default. This means that if I write catch(Exception), I could accidentally be catching what is effectively an assertion failure. Since assert() is supposed to be terse to encourage the programmer to use it liberally, explicitly passing AssertError to enforce() doesn't cut it. Mostly what I need here is a better/terser name than alwaysAssert(). Given the nature of this feature, I'd say terseness actually beats explicitness. The best I've come up w/ so far is rassert() for release assert. |
October 31, 2010 [phobos] A few minor features | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Simcha | On 31 okt 2010, at 16:54, David Simcha wrote: > 3. An alwaysAssert() function that stays on in release mode but is otherwise equivalent to assert(). I had been using enforce() for this, but I don't like that anymore because it throws Exception, not AssertError by default. This means that if I write catch(Exception), I could accidentally be catching what is effectively an assertion failure. Since assert() is supposed to be terse to encourage the programmer to use it liberally, explicitly passing AssertError to enforce() doesn't cut it. Mostly what I need here is a better/terser name than alwaysAssert(). Given the nature of this feature, I'd say terseness actually beats explicitness. The best I've come up w/ so far is rassert() for release assert. I think it's completely wrong that enforce throws Exception, it should throw an exception of its own type, like EnforceException. > _______________________________________________ > phobos mailing list > phobos at puremagic.com > http://lists.puremagic.com/mailman/listinfo/phobos -- /Jacob Carlborg |
October 31, 2010 [phobos] A few minor features | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On 10/31/2010 12:02 PM, Jacob Carlborg wrote:
> On 31 okt 2010, at 16:54, David Simcha wrote:
>> 3. An alwaysAssert() function that stays on in release mode but is otherwise equivalent to assert(). I had been using enforce() for this, but I don't like that anymore because it throws Exception, not AssertError by default. This means that if I write catch(Exception), I could accidentally be catching what is effectively an assertion failure. Since assert() is supposed to be terse to encourage the programmer to use it liberally, explicitly passing AssertError to enforce() doesn't cut it. Mostly what I need here is a better/terser name than alwaysAssert(). Given the nature of this feature, I'd say terseness actually beats explicitness. The best I've come up w/ so far is rassert() for release assert.
> I think it's completely wrong that enforce throws Exception, it should throw an exception of its own type, like EnforceException.
Agreed, I've been meaning to suggest that too. I guess it should be a subclass of Exception. It's still tangential to what I'm proposing, though, since IMHO whatever alwaysAssert() throws needs to be derived from Error and should probably be the same thing assert() throws.
|
October 31, 2010 [phobos] A few minor features | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Simcha | On Sun, 31 Oct 2010 11:54:18 -0400
David Simcha <dsimcha at gmail.com> wrote:
> 3. An alwaysAssert() function that stays on in release mode but is otherwise equivalent to assert(). I had been using enforce() for this, but I don't like that anymore because it throws Exception, not AssertError by default. This means that if I write catch(Exception), I could accidentally be catching what is effectively an assertion failure. Since assert() is supposed to be terse to encourage the programmer to use it liberally, explicitly passing AssertError to enforce() doesn't cut it. Mostly what I need here is a better/terser name than alwaysAssert(). Given the nature of this feature, I'd say terseness actually beats explicitness. The best I've come up w/ so far is rassert() for release assert.
Hello,
[New to D. Mainly subscribed to the list as a help in getting to know the lib quicklier.]
"Release asserts" seem to me nearly a necessary feature. (Precisely, bugs have the unpleasant habit of hiding during test phases.]
As for names:
predict(n != 0) playing with "predicate"
exclude(n == 0) reversing the assertion
The latter looks good to me in the sense contract.
Denis
-- -- -- -- -- -- --
vit esse estrany ?
spir.wikidot.com
|
October 31, 2010 [phobos] A few minor features | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Simcha | David Simcha wrote: > > The functionality is: > > 1. Static array literals that are guaranteed to avoid heap allocations: > > /** > Creates a static array literal, avoiding the heap allocation that results > from a regular array literal. > */ > CommonType!(T)[T.length] staticArray(T...)(T elems) > if(is(CommonType!(T))) { > typeof(return) ret = void; > foreach(i, Unused; T) { > ret[i] = elems[i]; > } > > return ret; > } I'd prefer fixing that in the compiler, I just haven't gotten around to it yet. > > 2. A function that allows the address of a nested function to be taken w/o a heap allocation. > > /** > Allows the address of a nested function to be (unsafely) taken without > resulting in a heap allocation. > */ > T scopeAddress(T)(scope T val) { > return val; > } > > Usage: > > void fun() { > void nested() {} > > auto addr = scopeAddress(&nested); > } > > 3. An alwaysAssert() function that stays on in release mode but is otherwise equivalent to assert(). I had been using enforce() for this, but I don't like that anymore because it throws Exception, not AssertError by default. This means that if I write catch(Exception), I could accidentally be catching what is effectively an assertion failure. Since assert() is supposed to be terse to encourage the programmer to use it liberally, explicitly passing AssertError to enforce() doesn't cut it. Mostly what I need here is a better/terser name than alwaysAssert(). Given the nature of this feature, I'd say terseness actually beats explicitness. The best I've come up w/ so far is rassert() for release assert. > So far, what I use for this is: if (!condition) assert(0); Even in release mode, assert(0) will execute a HLT instruction. |
October 31, 2010 [phobos] A few minor features | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 10/31/2010 7:38 PM, Walter Bright wrote: > > > David Simcha wrote: >> >> The functionality is: >> >> 1. Static array literals that are guaranteed to avoid heap allocations: >> >> /** >> Creates a static array literal, avoiding the heap allocation that >> results >> from a regular array literal. >> */ >> CommonType!(T)[T.length] staticArray(T...)(T elems) >> if(is(CommonType!(T))) { >> typeof(return) ret = void; >> foreach(i, Unused; T) { >> ret[i] = elems[i]; >> } >> >> return ret; >> } > > I'd prefer fixing that in the compiler, I just haven't gotten around to it yet. Ok, sounds good. I wasn't sure if this was on your todo list or not. > >> 3. An alwaysAssert() function that stays on in release mode but is otherwise equivalent to assert(). I had been using enforce() for this, but I don't like that anymore because it throws Exception, not AssertError by default. This means that if I write catch(Exception), I could accidentally be catching what is effectively an assertion failure. Since assert() is supposed to be terse to encourage the programmer to use it liberally, explicitly passing AssertError to enforce() doesn't cut it. Mostly what I need here is a better/terser name than alwaysAssert(). Given the nature of this feature, I'd say terseness actually beats explicitness. The best I've come up w/ so far is rassert() for release assert. >> > > > So far, what I use for this is: > > if (!condition) assert(0); > > Even in release mode, assert(0) will execute a HLT instruction. > Andrei pointed that out to me, too. I think that idiom is a terrible solution because: 1. It's too much typing. Asserts are something you want sprinkled liberally thoughout your codebase, and they should only be removed from release builds if they have a non-negligible impact on performance or might contain sensitive information that you don't want revealed to customers or whatever. It's absolutely essential that release-mode assert not be a PITA to use. 2. It doesn't give file and line numbers. |
October 31, 2010 [phobos] A few minor features | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Simcha |
David Simcha wrote:
>
> Andrei pointed that out to me, too. I think that idiom is a terrible solution because:
>
> 1. It's too much typing. Asserts are something you want sprinkled liberally thoughout your codebase, and they should only be removed from release builds if they have a non-negligible impact on performance or might contain sensitive information that you don't want revealed to customers or whatever. It's absolutely essential that release-mode assert not be a PITA to use.
>
> 2. It doesn't give file and line numbers.
>
Not the greatest, sure, but not exactly terrible!
|
Copyright © 1999-2021 by the D Language Foundation