Sean Kelly wrote:
> In article <d7i8pv$2a4k$1@digitaldaemon.com>, Brad Beveridge says...
> 
>>Firstly, I must admit that I haven't read this whole thread - so if this is OT for the thread, please let me know.  At least the subject is on topic.
>>
>>As I understand it, one of the primary reasons that D doesn't support constness is because it is hard (impossible) for the compiler to actually enforce constness.
>>
>>Reading the "final vs const" post I had a flash of something (perhaps insipration, perhaps I was just hungry); D supports DBC very well.  DBC is far more flexible than mere constness, so one of the things that could be enforced by DBC _is_ constness - at least at function entry/exit.
>>So since true constness is hard/impossible to implement, should D programmers perhaps adopt the idea that any place you really want constness, enforce it with DBC?
> 
> 
> See my reply to the "Java String vs wchar[]" thread :)
> 
> 
> Seab
> 
> 
Your reply is much more concrete than mine.
If I were smart enough I would have provided code too :)

Brad

Unfortunately, one of the tenets of Contract Programming (formerly known as DbC) is the principle of removability: code that is correct should not be affected by removal / insertion of contract enforcements.

Furthermore, Contract Programming enforcement is at runtime. While we can postulate that a compiler might be obliged to infer compile-time relationships from runtime contracts, this seems, at least at first thinking, to be a dubious notion, and likely to have only partial applicability.

"Brad Beveridge" <brad@somewhere.net> wrote in message news:d7i8pv$2a4k$1@digitaldaemon.com...
> Firstly, I must admit that I haven't read this whole thread - so if this is OT for the thread, please let me know.  At least the subject is on topic.
>
> As I understand it, one of the primary reasons that D doesn't support constness is because it is hard (impossible) for the compiler to actually enforce constness.
>
> Reading the "final vs const" post I had a flash of something
> (perhaps insipration, perhaps I was just hungry); D supports DBC
> very well.  DBC is far more flexible than mere constness, so one
> of the things that could be enforced by DBC _is_ constness - at
> least at function entry/exit.
> So since true constness is hard/impossible to implement, should D
> programmers perhaps adopt the idea that any place you really want
> constness, enforce it with DBC?
>
> Am I making any sense at all?  Perhaps not, but oh well :)
>
> Thanks
> Brad

In article <d7iup8$5j2$1@digitaldaemon.com>, Matthew says...
>
>Unfortunately, one of the tenets of Contract Programming (formerly known as DbC) is the principle of removability: code that is correct should not be affected by removal / insertion of contract enforcements.
>
>Furthermore, Contract Programming enforcement is at runtime. While we can postulate that a compiler might be obliged to infer compile-time relationships from runtime contracts, this seems, at least at first thinking, to be a dubious notion, and likely to have only partial applicability.

But const correctness can be verified, somewhat, using DbC and a lot of cooperation.  And since D currently offers us nothing in this regard, perhaps it's an approach worth mentioning.


Sean