On May 12, 2016, at 4:03 PM, John McCall via swift-dev <swift-dev@swift.org>
wrote:
>>> 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?
We cite Wikipedia in the stdlib doc comments, why can't we cite TSPL, and put
the detailed discussion there?
-Chris
> John.
> _______________________________________________
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
