> On May 12, 2016, at 3:21 PM, Joe Groff <jgr...@apple.com> wrote:
>> On May 12, 2016, at 11:21 AM, John McCall <rjmcc...@apple.com> wrote:
>>
>>> On May 12, 2016, at 10:45 AM, Jordan Rose via swift-dev
>>> <swift-dev@swift.org> wrote:
>>>> On May 12, 2016, at 10:44, Joe Groff <jgr...@apple.com> wrote:
>>>>
>>>>
>>>>> On May 12, 2016, at 9:27 AM, Jordan Rose via swift-dev
>>>>> <swift-dev@swift.org> wrote:
>>>>>
>>>>>
>>>>> - I’m uncomfortable with using the term “undefined behavior” as if it’s
>>>>> universally understood. Up until now we haven't formally had that notion
>>>>> in Swift, just “type safety” and “memory safety” and
>>>>> “invariant-preserving” and the like. Maybe we need it now, but I think it
>>>>> needs to be explicitly defined. (I’d actually talk to Dave about exactly
>>>>> what terms make the most sense for users.)
>>>>
>>>> We do have undefined behavior, and use that term in the standard library
>>>> docs where appropriate:
>>>>
>>>> stdlib/public/core/Optional.swift- /// `!` (forced unwrap) operator.
>>>> However, in optimized builds (`-O`), no
>>>> stdlib/public/core/Optional.swift- /// check is performed to ensure that
>>>> the current instance actually has a
>>>> stdlib/public/core/Optional.swift- /// value. Accessing this property in
>>>> the case of a `nil` value is a serious
>>>> stdlib/public/core/Optional.swift: /// programming error and could lead
>>>> to undefined behavior or a runtime
>>>> stdlib/public/core/Optional.swift- /// error.
>>>> stdlib/public/core/Optional.swift- ///
>>>> stdlib/public/core/Optional.swift- /// In debug builds (`-Onone`), the
>>>> `unsafelyUnwrapped` property has the same
>>>> --
>>>> stdlib/public/core/StringBridge.swift- /// The caller of this function
>>>> guarantees that the closure 'body' does not
>>>> stdlib/public/core/StringBridge.swift- /// escape the object referenced
>>>> by the opaque pointer passed to it or
>>>> stdlib/public/core/StringBridge.swift- /// anything transitively
>>>> reachable form this object. Doing so
>>>> stdlib/public/core/StringBridge.swift: /// will result in undefined
>>>> behavior.
>>>> stdlib/public/core/StringBridge.swift-
>>>> @_semantics("self_no_escaping_closure")
>>>> stdlib/public/core/StringBridge.swift- func
>>>> _unsafeWithNotEscapedSelfPointer<Result>(
>>>> stdlib/public/core/StringBridge.swift- _ body: @noescape
>>>> (OpaquePointer) throws -> Result
>>>> --
>>>> stdlib/public/core/Unmanaged.swift- /// reference's lifetime fixed for
>>>> the duration of the
>>>> stdlib/public/core/Unmanaged.swift- /// '_withUnsafeGuaranteedRef' call.
>>>> stdlib/public/core/Unmanaged.swift- ///
>>>> stdlib/public/core/Unmanaged.swift: /// Violation of this will incur
>>>> undefined behavior.
>>>> stdlib/public/core/Unmanaged.swift- ///
>>>> stdlib/public/core/Unmanaged.swift- /// A lifetime of a reference 'the
>>>> instance' is fixed over a point in the
>>>> stdlib/public/core/Unmanaged.swift- /// programm if:
>>>
>>> Those latter two are in stdlib-internal declarations. I think I have the
>>> same objection with using the term for 'unsafelyUnwrapped'.
>>
>> Well, we can say "A program has undefined behavior if it does X or Y", or we
>> can say "A program which does X or Y lacks type safety". In all cases we
>> are referring to a concept defined elsewhere. If we say "undefined
>> behavior", we are using an easily-googled term whose popular discussions
>> will quickly inform the reader of the consequences of the violation. If we
>> say "type safety", we are using a term with that's popularly used in very
>> vague, hand-wavey ways and whose consequences aren't usually discussed
>> outside of formal contexts. If we say "memory safety", we're using a term
>> that doesn't even have that precedent. So we can use the latter two terms
>> if we want, but that just means we need to have a standard place where we
>> define them and describe the consequences of violating them, probably with
>> at least a footnote saying "this is analogous to the undefined behavior
>> rules of C and C++".
>
> In other places where the standard library intentionally has undefined
> behavior, it looks like we use the term "serious programming error", for
> instance in the the doc comment for `assert`:
>
> /// * In -Ounchecked builds, `condition` is not evaluated, but the
> /// optimizer may assume that it *would* evaluate to `true`. Failure
> /// to satisfy that assumption in -Ounchecked builds is a serious
> /// programming error.
>
> which feels a bit colloquial to me, and doesn't provide much insight into the
> full consequences of UB. I think we're better off using an established term.
Agreed.
Do we have a good place to document common terms? Preferably one that isn't a
book?
John.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
