View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000260 | LDMud | LPC Compiler/Preprocessor | public | 2004-11-27 00:11 | 2009-10-01 05:21 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Summary | 0000260: Make '>' indexing default, with an option? | ||||
| Description | Short: Make > indexing default with an option ? From: Tomba@Batmud Date: 2001-08-25 Type: Feature State: New Anyway, I was wondering what's the difference between normal indexing and > indexing. Isn't normal indexing just a subset of > indexing? If so, why not default to > style indexing and add a compile time option for allowing or disabling negative indexes. Just to clear up a bit, arr[-2] would be the same as arr[>-2] etc. Batmud's old driver works this way, and even if I have already made my own changes to ldmud to allow negative indexing, it'd be nice to have it by default. =) And Alfe said to this topic: Alfe says: man koennte vielleicht folgendes sagen: Alfe says: x[>a..>b] ist das, was x[a..b] bisher ist. Alfe says: x[a..b] ist das, was extract(x,a,b) bisher ist (d.h. vorzeichen legt fest, ob von rechts oder links). Alfe says: und x[<a..<b] ist wie gehabt. Alfe says: aber dann muesste man mal durchs mud gehen und alle vorkommen von x[a..b] ueberpruefen Alfe says: du kannst nicht garantieren, dass ein x[a..b] bisher immer mit positiven werten arbeitete, also solltest du besser davon ausgehen, dass alle stellen potentiell auch mit negativen werten passieren koennen. Alfe says: demnach stehe ich dieser version etwas ambivalent gegenueber. Alfe says: es waere zwar sehr schoen, wenn das < sagt: von rechts, das > sagt: von links und sonst sagt das vorzeichen das. Alfe says: denn das ist logisch strukturiert. Alfe says: so gesehen waere es vielleicht besser, wenn das x[>a..>b] bedeutet, dass das vorzeichen entscheidet und x[a..b] wie gehabt bleibt. | ||||
| Tags | No tags attached. | ||||
| External Data (URL) | |||||
|
|
Just until now I thought, that indexing with negative numbers/ranges is deprecated but I seem to be wrong. Can anybody tell me about the real purpose of indexing something from before the beginning? |
|
|
Single indices (a[x]) are not allowed to be negative, but indices in ranges can be (a[-1..x] is the same as a[0..x]). Ranges are much sloppier than normal indexing operations. |
|
|
Mhmm, is it feasible to deprecate negative numbers in ranges and issue warnings and errors with pedantic (and later even without). Or is that too heavily used? |
|
|
Can't say without warnings... (With the deprecated indexing past string ends we got more warnings than I expected, so there might be a lot of that around, too.) |
|
|
One the one hand, as long as the driver ensures all ranges that start below 0 to be remapped to 0..rangemax I would rather call it a feature than a bug. It allows for a very easy-to-use way to get that last n elements (or less if there are less than n elements at all) of an array/string. On the other hand, this possibility implies, that I should also be able to get the first n elements of an array/string by [0..(n-1)] - which might complain about indexing past string end. So, for the sake of consistency, I would opt for deprecating negative indices. |
|
|
Ok, but that is possible without negative indices: [0..n-1]: first n elements [<n..]: last n elements This negative indices I meant was [-3..-1] which is the empty array/string and [-2..2] which is [0..2]. I don't really think, you need the negative indices as they are now (for other than backwards compatibility). Something else would be to use the sign instead of <. That [-3..] would be the last 3 elements, but to change to this will silently break code and I would not like that. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-11-27 00:11 |
|
New Issue | |
| 2009-09-30 17:25 | zesstra | Note Added: 0001373 | |
| 2009-09-30 17:33 | Gnomi | Note Added: 0001375 | |
| 2009-09-30 17:37 | zesstra | Note Added: 0001376 | |
| 2009-09-30 17:44 | Gnomi | Note Added: 0001378 | |
| 2009-10-01 05:08 | Sorcerer | Note Added: 0001390 | |
| 2009-10-01 05:21 | zesstra | Note Added: 0001391 |
